IBM FileNet Reviews

We use it for monitoring events, authorization of events, for communication among all teams, all divisions of the company. It is difficult, for example, to manage a case throughout the company. BPM is no good, and Case Manager is so elastic, so flexible.

It helps with tracking cases, tracking problems, it's so good for that.

The designing. The design of development is so easy. It's a good product for designing flows, BPMs, and configuring roles.

I would like to see them improve the capabilities in the cloud, and the analytics.

It's so stable.

Scalability is good. I don't know about the cloud version, but it's good.

Good.

It's easy. The most challenging part of implementation with this product is designing the case and the flows.

When I select a vendor, the most important thing is the possibility to move to other technologies, connectivity for the digital ecosystem, and sharing; how the product shares sets for other companies.

I rate it eight out of 10, because it's stable, it's elastic, but difficult for designing the business use case.

Before implementing the product, try to pilot it, in a small division, work it in a small division and then try to scale.

We use IBM Case Manager as our platform for deploying our telemedicine solution. The use case is delivering connectivity between patient and doctor without any third parties. The cognitive capabilities of Case Manager and how we're able to create a case, which is a patient, are very valuable for us. Everything that goes into an object is about the patient, versus it being event driven.

The most critical benefit has been ease of use. It speeds along our development, helping us go to market a lot sooner.

It's cognitive capabilities and scalability. 

I'd like to see more cognitive. That's obviously where all of our world is going. I think if we can have more of those types of features and functions as a core, out of the box, that would be very helpful for us and our space.

Excellent. It's probably one of the most mature pieces of technology that IBM offers. 

I believe we built it on that platform because of its ability to scale to whatever size we need to go to.

We're consistently using technical support and they're doing a great job to this point.

We started with IBM Case Manager after doing our research on some of the other ones, just sampling them. We saw that the other ones didn't have the scalability and were very easily breakable.

For me, the most important criterion when selecting a vendor is trust.

There's a level of complexity, but our exposure, for starters, has been with the IBM Concierge, where the solution is fully loaded already, Case Manager on all of its platforms. But when we try to do it ourselves, that's not as smooth. 

We started with considering doing a peer, mobile-first type application. Obviously, from a mobility perspective that's great, but you need a lot more heft from data storage and otherwise. 

I will rate it at eight out of 10, because I think some of the technical pieces, when implementing it ourselves, were something of a roadblock until we discovered the Concierge. Those are some things they have to work on. We'd like to be a lot more independent for something like that. But outside of that, from what it delivers in terms of functionality, it's great.

My advice would be, respect the maturity of the solution if you're trying to go to a huge scale. Most new stuff breaks.

In our organization, we have a lot of documents, such as policies. It is very critical for our organization to have safely and securely stored content in our system.

FileNet is the best tool in the business for our organization to store all our content, policy documents, and claims.

We have been using FileNet since 2000. Since then, we have been upgrading our file systems with a lot of tools and the latest file systems.

It has improved my organization by how we release documents, claims, and policies. It is very important to quickly review documents to make the customer satisfied. This is solved when we use the product.

It is a faster, robust solution. The platform compatibility is very good.

To start with there are too many add-ons, which makes it hard for us. If they simplified the add-ons and plugins to be added to our existing systems, it would definitely help us in the future.

Stability is really good. Earlier, we used to have a lot of issues with the stability, especially with the updates for the new products. The new additions made now are so stable. It is a very good for operating systems. They have simplified it using products in different situations.

Scalability is really good. Earlier, it used to be a cluster-based solution. Now, with the latest versions over the last five or six years, we have a form architecture, which we produced. We find that it helps for scaling all of our systems to our service.

We use IBM support quite a lot. We have a license with this product, then whenever there are any issues, we always contact IBM to get them resolved.

The beauty is the response time. It is very good nowadays within the platform.

Earlier they used to have a very basic version of FileNet, the content services. That was back in the mid 90s. We also had the product that were being used on the FileNet site and also having too many issues. They came up with the new products like FileNet, which made it easier to store the documents. They added more security on top of the documents. So there's a lot implements that happened over time.

The main product we use is IBM based products, FileNet, the case manager and that stuff. On top of it we build a lot of APIs and other services and that includes supplemental customer applications. So for that, we mostly work with our participating companies who are rather preferable for our company.

It was complex. There were a lot of dependencies depending on the product. It had to be compatible with the Windows matching. All the time it had to be compatible with X and OS, so we did not have dependencies with all the operating system rights. 

For the medium scale or large scale, I would recommend FileNet. FileNet is free of licensing expenses, thus good for the money. It is not expensive, but worth for the money, especially for medium scale and large scale industries.

For small scale industries, they allow different options. They can do open source. It is the complexity of the data security that they should think about before they choose.

There were a lot of other vendors trying to overtake it, like Hyland, for more than 15 to 20 years. FileNet has had the same platform which is stable, but it is very compatible with our requirements. It supports OS, Linux, Oracle and digital, making it more flexible than most products on the market.

We use FileNet with our Cognos. We used to store all of our report history within Cognos, inside the content store. We've removed it from the content store and put it inside the FileNet system. Our users can still access their reports, but we don't have to store it in our content store.

Our main benefit is keeping our content store small, where our content store was about 5.5GB. Best practices from IBM is about 3GB, so we were way over that. By moving all the report history out of the content store, we're now down to about 1.5 to to 2GB.

Keeping our content store small. That helps our DBAs when they have to do the backups of our audit system, or of the content store. It's in SQL Server, and to back up SQL Server of something that size takes a lot of time and a lot of effort. But now that we've shrunk that down, it's a little bit more manageable to handle backups. I know if we do ever have to restore our content store - which we hope we never do - we're able to do it in a more timely fashion because it's smaller in size.

It does what we need for it to do. As long as it can continue to handle the volume that we're throwing at it, I don't think that it's going to be a problem.

We've been using it now for about four years. When we first went to it, we were having some issues, communication across the network issues, but we have had very few issues with it. 

We add stuff to it all the time, so it's scaling vertically all the time, and we haven't had any issues with it. We started out around 3GB, and we're up to about 5GB, and we expect to be somewhere at around the 10 to 12GB mark by 2020, just because that's the way our business is growing.

One of our account reps was very instrumental in getting us set up, but we really haven't had, other than network latency issues in the very beginning, a lot of issues where we needed to go to technical support for it.

We were using the out-of-the-box content store of Cognos, and we were just busting at the seams, so we had to come up with a solution. One of our account reps actually came up with the solution. We looked at a couple other things, but this was a solution we decided to go with.

The important criterion for us when selecting a vendor is mostly that it's going to handle volume. Our particular company is a distribution system, and so we have tons and tons of data, so we need to be able to handle volume. What we typically run into is, people give us a proof of concept, and it will handle it with a small use case. But when you try and explode that use case into something that we need, at the volume we're working at, many of those solutions just fall flat at that point. This particular solution, that didn't happen. 

It was pretty straightforward. Like I said, the biggest issues we had were on our company side, the network latency of moving that much data across our network at one time. Once we opened up a dedicated pipe for that data movement, we haven't seen any issues like that.

I'd give it an eight out of 10. Eight's not high, not low, necessarily, but it does everything we need. I'm not going to give anything a 10, but I'm definitely not gonna give it a one.

I would say you need to take a look at the size of your content. If you're going to use it to replace the content store of Cognos, you need to look at the size and make sure you're within best practices. Cognos is a product that's wishy-washy at times, and most of the issues that we've ever had with Cognos were because our content store was too big. Now that we've shrunk the content store, our Cognos is actually better. If you are looking at that, this would be a solution I would suggest to you, just to keep your content store small.

The primary use case is for collaboration of data files through CCM with IBM Connections. It provides an information sharing space and ability to create folders, thus managing the data. We are a worldwide company with offices all over, and there is a community room setup leveraging CCM with FileNet as the back-end. Therefore, all these users upload their files and collaborate on them in this space.

Now, it is performing pretty well, since I have upgraded to the 5.5 version. Historically, we have had a lot of problems with it. 

IBM FileNet has improved our organization with its single collaboration space.

• The ability to manage the content well. 
• To create folders (unknown: how much is on the FileNet back-end versus CCM front-end).
• The ability to tag data, as it seems to be indexed well. It is a good space to manage data, keep track of it, and organize it.

• A little better control into the ACLs of FileNet and databases. 
• A better administration tool. At the moment, we are using the ACE tool, which is a web-based administration tool whenever we have to deal with the FileNet back-end directly. It is kludgy and slow. They used to have a rich client tool that performed much better, but they discontinued it. I would love to see that tool come back in order be able to do more effective, efficient administration of FileNet on the back-end.  
• It needs better collaboration between the IBM teams on the FileNet and CCM sides.

Now, they are pretty good.

In previous versions of Connections 3.0, 4.5, and 5.0, I had a lot of stability issues. It gets a little muddy, because when I would open PMRs, sometimes they would be on the connections interface on front and sometimes they would be on the back. One of my challenges seemed to be that there seemed to be a lot of disconnect between the two teams. It is empirical evidence, but it seems to me  that the Connections developers leveraged the FileNet capabilities and the right hand did not know what the left hand was doing. There seemed to be a lot of disconnect between the two teams. I would bounce back and forth between the two teams for weeks or months just trying to get support on performance and stability issues. With the most recent upgrade that we did a year ago, these issues pretty much stopped. 

Scalability is so far good. We have great adoption with the tool. For the users that we are supporting to date, it seems to be handling the load and performing well. 

My experience with the technical support is mediocre. Often times, I would open a ticket and the technical support would label it as a FileNet issue, then send it to the FileNet team. The FileNet team would receive it and declare it a Connections issues, thus creating a back-and-forth between teams until I insist on getting both teams on the phone and fight it out. I am the customer in this situation. I just want the issues fixed and resolved.

It has gotten better. However, I do not have many issues with the system now.

I do not know about previous solutions, but the business decided that it wanted CCM, which leverages FileNet. Therefore, I installed, configured, and built the infrastructure.

The initial setup was straightforward.

The Connections teams, as far as the FileNet tool, were able to integrate it with CCM. They made it easy to set up. At the time you install Connections, you point to the FileNet installers and it does all the work for you. There are a few manual steps, but all of that is pretty well documented. It is a lengthy process and straightforward, but it will take a lot longer than five minutes. 

None that I am aware of.

Do your homework. Test it thoroughly (all the standard stuff). Do load testing to make sure it is a stable platform. Look at the life-cycle of the product.

Most important criteria when selecting a vendor: support. Not just technical support when you have a problem, but how long before you are discontinuing a product. Right now, I am dealing with Connections over an issue with Java going out of date and they are not supporting it very well. Their solution is to force us to upgrade. 

Look at the support aspects of the product from life-cycle of the product to technical support. Obviously, stability of the product as a whole is important. I do not want to be opening a lot of tickets.

We use FileNet to store all our content. We have a quarter of a billion documents stored and it works great for us.

It has taken the manual work out of our billing process, and automated it.

We actually use it in conjunction with BPM to auto-bill our customers, based on when the bill gets checked into FileNet.

I would love it if single sign-on was a lot easier to set up. That's the most difficult part of it.

We have it load-balanced, so we don't really have outages. With HA it's very stable.

It could be easier to scale, but in our implementation we can build up a new server and a whole new environment in about a day and a half.

It would be nice if they could make it like containers are working in Kubernetes to auto-scale based on demand.

I've used it quite often. Technical support could be better, more responsive in a timely manner. I've learned to actually open up tickets earlier in the morning because you seem to get better help than if you wait until the afternoon.

We didn't have a previous solution. We went with FileNet as our content repository from the beginning.

When selecting a vendor we like to have somebody that can provide good support and a good business relationship; we like to build relationships with our vendors.

It's very complex. We have a lot of pieces that tie together with our FileNet, like  domains. So it's complex.

I would give it an eight out of 10. What it needs to be a 10 is easier to configure single sign-on.

I would recommend that when you are doing the initial setup that you use fewer metadata fields. The fewer you use the better off you're going to be in the long run, for performance.

We had several use cases. We used it for all of our loan processing and we took a 21-day manual process down to three. We also used it for all of our credit applications, and that took a 45-day process down to two. It housed about 4TB of data.

Performance was great. It was our system of record.

No one was wondering where a document was. They could all go and find out exactly what they needed, when they needed. It wasn't, "Who's got this and who's got that?"

The most valuable features are the interconnectivity and the collaboration. No longer do I have to wonder what system I need to go to for the data I need. I know it's in FileNet.

We wrote several custom applications for the users to dive in and be able to find the data they need. 

If there was more AI capability, into Watson, that would be a benefit.

Also, where are the users going to find the documents? Because that's a path we don't see. We know that they're looking at documents, but we don't know what documents they're actually going and finding the most, or where the bottlenecks might be. It would be nice if there was some interconnectivity back into Bluemix to say, "Ok, you've got a workflow problem here." That would be a neat feature moving forward because we've got a lot of users that would just say, "The system is not working." We had a few threads would get hung up because they were just constantly banging on these few documents. If that were the case, if we knew that ahead of time, then we could fix that, change the search sequences to make it more efficient. But we were blind to that until the users said it's not working.

It's extremely stable. The only time it ever had a problem was if we lost power to the servers. It never really went down.

It was very scalable. If we needed to add more processing power we could just add another server, turn it on, and then we had more power. We didn't have any scalability problems.

We did use technical support for a while. enChoice was one of the partners we used with IBM. They're a great partner. Eventually, I was able to hire enough of our own staff that we did much of our own support.

My experience with technical support was good. Any time we needed them they were right there for us.

We were all manual before and we knew we needed something.

The most important criteria when selecting a vendor are

• commitment
• partnership - we're in this together.

IBM doesn't succeed if I don't succeed, and I can't succeed if the product doesn't work well. If there isn't that mutual give and take, then no one succeeds. It's more about: Any solution can be thought of and fixed and made to work, but you have to be able to work together. If I just sign up and give you a check and then you walk away, that doesn't help me. I need to sign up and then you be there with me, through the process.

I was not involved in the initial setup. From what I understand, when they first set it up it was rather complex. They had some hurdles to jump through. It took about two years to really iron out all the kinks. We had a vendor prior to enChoice that we weren't successful with. When we found enChoice, things started to turn around. So it's important to pick the right partner.

They evaluated Documentum, they evaluated FileNet, they evaluated a few other tools. The company actually bought FileNet before IBM bought FileNet, so we had a contract with FileNet and then IBM came in and bought it. That was a good thing because of the innovation that IBM did bring to the platform. We were also a heavy C|MAN user and the content management on-demand system integrates well with FileNet too. With the new Content Navigator, it allowed for one pane of glass. So what IBM is doing in that area is just going to keep getting better.

I would give the solution a nine out of 10. If it were free I would give it a 10.

Go find an industry that is the same as yours, that is using the tools you want to buy, and find out if they're successful. If they're not, don't go with those tools. For example, I'm in energy now and I'm looking for people who are using Maximo, who are using the other tools from IBM, and I want to talk to them: Are you successful using these tools?

Don't do it in a vacuum, you've got to talk to people.

It's an image repository for our medical documents, our claims, etc. They do all kinds of stuff. They put checks there. It's an indexing software.

It has added more indexing capability on images and enabled us to search them. 

Stores a lot of documents. It's a good repository for that.

What I would want to see is heavier analytical ability within it, but we've purchased the cognitive piece of it. I haven't seen that implemented yet, but that would be the future; I think it may already be there but I just haven't seen it yet. Something like indexing for unstructured text.

At this time, it has improved, but it wasn't that stable not that long ago. 

It seems fine, it's dynamic. It works with all the different business needs that we have for it.

I have not used tech support for this solution.

When selecting a vendor the important criteria are 

• cost
• ease in getting something accomplished
• not over-promising 
• trustworthy.

I would rate it a seven out of 10. That rating is because of stability problems when I first had it - and then, I'm not entirely sure our company has set it up right. Sometimes things are only as good as the people who run it. It's like going to a restaurant. It's only as good as the chef. So you can go to Burger King and have a pretty good burger or you can go down the road, it just depends on how good the chef is. So I think there's some of that dynamic. I don't know that much because I didn't mess with it like at that level. But it's a fine product. We've used it for a very long time.

The advice I would to a colleague at another company who's researching this or another similar solution would be to check how data index with one another, and the communication back and forth in being able to find your files, if you have a large data set like we do.