IBM FileNet Reviews

We're in the process of implementing it for what we call a product plan approval process. It's going to be used by project managers to submit their product plans to our department that will then go on and approve them.

For example, if they want to produce a pamphlet, or a website in support of a particular objective, they will hit our product plan system to input what they want to do, what they want to produce, and then it will go through an approval process. Then they'll be able to produce it in whatever languages they decide that they want to produce it in. It's more an approval workflow that we're using it for.

We will also use it for integration back to our product lifecycle management system, as well for our materials management division.

It's a lot simpler than us doing in-house development of it and managing it, so that's part of it. But the overall improvement I'd say is through the ease of automation, it takes away a lot of manual processes.

The workflow. I would say the workflow is pretty good. Also, the flexibility of being able to create custom objects with a lot of domain-specific attributes that we follow.

One of the things I know is a bit of a challenge for them - because I know that it lives on top of FileNet, so it's not necessarily living on top of a relational database, per se - is that we also are using it as our system of record for our language management and our language definitions. I know that that was a little bit of a challenge, just because of the underlying architecture.

So far, so good, but we're also very new, in this implementation particularly.

I still don't know about the scalability yet.

We've been using an implementation vendor to help us get rolling with it, a company called Vega. They've been very helpful.

I was involved in a lot of the planning, and specifically for the technical aspects of it, integration and data migration. It seemed pretty straightforward.

When selecting a vendor what's important are the 

• product
• service, response
• name and reputation.

We definitely look for somebody that we can trust, that understands our vision, that is reliable, that really is going to do their best to kind of help meet our needs without necessarily trying to push us into a corner.

I would give Case Manager a seven out of 10 at this point, because I think there has been some challenges with trying to get the language library. I know that we do have some individuals that do need to come up to speed on it technically, and the only onsite training for Case Manager is in Europe, there is not a lot of US-based training. So they have to do all their training online rather than being able to go and have a good bootcamp-style training somewhere nearby.

In terms of advice, I would say use our partner, Vega, because they've done a really good job. It's been, honestly, one of the quicker implementations that I've been part of, overall. They've done a really good job coming in and understanding our business scenario, our business case; the speed of delivery is actually really impressive. We're going to be going live either end of this month or beginning of next month. It's been six months to replace something that has been broken into two different pieces that we're merging into one, but that have been parts of solutions that have taken us much, much longer to put together.

It is primarily used for storing documents and other content in our repository for underwriting purposes.

I have been using it for a little over two years now. I think it's been working out great for what our needs are.

Case Manager is a web-based application. The product we were using before Case Manager was a desktop application. We had a lot of issues with that product. Ever since moving over to Case Manager, it's been really easy and simple to use, and it's just perfect for the job.

I think it's valuable that users are able to create their own content, and they can manage their own sets of tasks, to work at their own pace and get their jobs done.

In terms of upcoming releases, I was in a couple of sessions on the IBM Case Manager roadmap, here at Think 2018. I think it's really cool that they're now taking the time to listen to their customers, and bring features in that customers have been asking for, for years.

One of the features that I thought was very cool is that you can edit your documents within your repository straight from your desktop, from your device. You don't have to have a special editor. It will just connect to the native application that the file works with, and you can just check right back into your repository. I thought that was very cool.

In my opinion, it is very scalable. We have couple of smaller solutions that are maybe 20 to 30 users, and then we have bigger solutions - we're talking hundreds of people using it at the same time. I think it's pretty scalable and stable.

I have been using IBM technical support to work with IBM to hash out their glitches, bugs on the product. I think that IBM has been very helpful. They are very professional when it comes to working with their customers. It's very helpful.

I was not involved in the initial setup.

The only way to really tell is to try it out, see how it works for you. I think it's a great product.

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.