IBM FileNet Reviews

We usually use it for document management in insurance or finance companies. Some of our clients are using the workflow for insurance cases. In these companies, FileNet is ingesting a lot of documents and a lot of insurance claims.

In terms of automation, we're using IBM Content Collector and we have started using RPA a bit. We're using ICC for some of our customers to ingest and automate the upload of multiple documents in bulk. We've just started using automation with RPA but not with the P8 system; rather for other functionality that customers need.

Ninety percent of our customers in the insurance industry, here in Israel, are working with FileNet.

Most of our customers use FileNet on-prem.

Filenet saves time in terms of clearance of insurance claims. Building a claim, from the customer side, is often easier as well. Not everything is perfect but it's good enough to work in most of the big insurance companies here in Israel.

Most of our customers are not using some of the most valuable features, like analytics, text search, or case or workflow features. They are generally not used by our customers because they're using other programs that are built-in to their networks. So if a customer has a workflow system already, he won't use the workflow system that is built-in to FileNet, although it's available.

It's the same with the content analytics. If the client has Kibana and Elasticsearch for searching text, they won't use that feature that comes with the FileNet P8 because it's only for the P8 system and not for the whole network.

The analytics in FileNet are too complicated and they consume too much infrastructure, memory, and CPU. They're too expensive to work with.

The usability, with the addition of Content Navigator, is not good enough. We're building our own interface, doing a facelift of the product, to satisfy our customers. People here in Israel are generally more Microsoft-oriented. They're used to the SharePoint look and feel, the Outlook look and feel. When they see Content Navigator and its features, it's a bit different for them. It's hard for them to get used to it.

Most of our customers and users are asking for features with a file-system-type look and feel. For example, when they open a folder in their file system they want to see the hierarchy of the folders. If IBM built something like other products, like M-Files for example, with a file-browsing feature, into P8, it would be a very good feature. Most customers around the world would use it.

That is what we're trying to build on our own. It would be easier for the customer to work with, in the same way IBM did with the Content Navigator Office Integration. There, you can browse through Office, the folders, and find things. You can drag and drop documents from Word, from Outlook, straight into the file folder in FileNet. If they would bring these kinds of features into the file system itself, without Office, it would be a killer feature.

I have been using FileNet for 20 years.

We have been working with it for a long time. It's one of the older versions. Both it and the new version are probably very stable.

We generally don't have any issues with the stability of the system. That could be because we are too small. In Israel we have small companies and they don't have very complicated systems, like in the United States or Europe. We have medium-size customers, compared to companies around the world. We don't have 500 users at a customer's site so these are not huge systems. And they're usually in the same geographical area. It's not like there is a site in New York and another one in Chicago or Philadelphia.

There are no issues with scaling. It's based on WebSphere Application Server so it's very easy to scale up.

I've contacted tech support many times. I don't have very much good to say about it. The people in support are changing often so most of the people there aren't familiar with the product. They are always asking for the basic information about the system, even though we've worked with finance customers for many years and we know the product. We try to provide the actual error to customer support and to get an answer about it. But until they forward it to first-level support or engineering, we lose time. We are not usually satisfied with customer support.

We used to use M-Files and we are a little familiar with Alfresco and Documentum. Generally, the biggest difference between those solutions and FileNet is the price. The others are much cheaper but most of them are less robust and less stable than FileNet. Programming and manipulating other programs to work with FileNet is easier than in Documentum, as far as I know. Each one has its own best features. It depends on the use case.

The initial setup depends. If we're talking about a Windows-based installation, it's very easy. For other operating systems, like Linux, it's a bit complex. If we're talking about the whole P8 suite, it's very complicated. Documentation on how-to, screenshots, or step-by-step instructions are missing in all of IBM's P8 finance products.

Unlike Apple or with other vendors, where you've got to book, you can install it without any understanding of the underlying system. In finance, with P8, if you are not familiar with bits and bytes you won't end up completing the installation.

In terms of how long it takes, if we're talking about only Content Navigator and FileNet P8, a basic system, just the installation could take three to five days. And that's not talking about the implementation. It depends on the customer's site, on the operating system, on the database vendor. Sometimes the version doesn't support it. It also depends on the network. It depends on a lot of things that are not straightforward.

We have a standard implementation strategy that we use for our customers. We're usually asking for Microsoft Windows operating system and either a SQL or Oracle Database, and we are not doing any other complex installation configurations like a very sophisticated single sign-on. That's because it doesn't work very smoothly.

The ROI on the automation aspect of FileNet is a big question. I don't have specific numbers. We're dealing with between 30 and 40 customers here in Israel, and every customer is different.

Within the IBM DBA (Digital Business Automation) portfolio we use Datacap and we do see a return on investment from that. The automated document scanning and email scanning show a very good return on investment.

If you are a small or medium-sized company, I would advise working with other programs before you put money into FileNet, even though I've worked with it for a long time. If we're talking about a large company, for the robustness, stability, performance, and the growth — that you can grow it within seconds — I would advise using FileNet, without any doubt.

The performance is dependent on the database. Issues with performance are usually associated with databases issues. And, as I mentioned, the GUI of IBM Content Navigator caused a lot of issues with performance, but it's working well with our GUI.

I would rate FileNet at eight out of ten. It's not a ten because of issues like the flexibility of the system, the ease of working with or manipulating or programming and enlarging it. It needs to be more flexible to work with, not hard-coded and not closed like it is now.

I work in the account-opening process, and we have IBM BPM, Workflow, and FileNet document repository. We use different products to generate documents. Our solution uses IBM BPM Workflow in which people fill out a questionnaire. That gives us a document that we store in FileNet. We deliver those documents either physically or via DocuSign. We get them signed to open the account.

It has increased productivity. And while I don't know for sure, because I am not from that group, I believe the solution has reduced operating costs. It has saved time as well. I have heard that it has reduced the time needed to open an account from 20 to 25 days down to a day.

Because the account-opening process varies on a case-by-case basis, we may have several documents generated for a particular case. We would like to put them in one client section. API-wise, it gives us the ability to create an end-to-end transaction.

Before we ask for any documents from customers, we would like to automatically see if any of them are already in our system. Are the documents signed already? We need to know before we have them sign a document that the document has already been signed. That is done manually, it's not automated.

Also, I have heard that there is already an integration with DocuSign. That was one of our needs. We brought DocuSign into our company's solution three years before. At that time there was no direct integration. We wanted to pull documents out from FileNet, push them to DocuSign and, when done, retrieve them and store them back in FileNet. We wrote our own custom solution for that. It would be nice if there was some tool we could have used to do that.

It would be helpful if I could submit a question and get a bunch of documents back. I would like to be able to query the documents that are already in the system and then we wouldn't have to worry about some of them because they're only year-old documents. If there is a document that is three years old we may have to re-ask for it from the customer. Such a rules-engine is not available.

Moreover, the questionnaire we use to generate documents is in XML and then it's coded in a scripting language. If there were rules it would be easy to configure them to pull out a specific document. The business cannot find what documents are in a given area right now.

Stability-wise, the solution is good. There is not much downtime. I don't see any issues with it.

In terms of scalability, we started with about 100 relationship partners and now we have around close to 1,000 partners, so it's quite good.

Technical support is going well. There are a few issues, but we have set up several monitors for our technical modules.

The initial setup is a bit complex unless you know some scripting languages. It's pretty complex.

Within the solution we have several products like BPM, Oracle Service Bus, as well as a lot of custom applications. The bank has its own deployment procedure that we follow for the specific products. IBM BPM is separate and we have laid out our own process. There are a couple of automated ways of doing it, but we follow the bank procedures.

The products we are using from the IBM portfolio include FileNet, IBM Case Manager, Content Navigator is there, and Datacap. We have integrated FileNet with different bank solutions. The integration process was good.

My advice is to set up rules in an outside programming tool. Put them in a separate configuration tool and make an API call to find a list of the documents which match. It would then show the list of the documents to the partner who is trying to open the account. Currently, sometimes they send a request and they get a bunch of documents and they say, "This isn't what I want, I want something else." Then they change the question and the region of the documents. To preview a list of the documents we have to generate the documents. The reason we cannot preview is because the rules are coded in our system instead of being externalized in a separate configuration.

We are not doing anything around automation at this time. We are just capturing the documents but we are not analyzing them. My team is looking into expanding into automation, as is the architecture team. There have been meetings with IBM recently on that.

The use of the solution within our organization is growing. A lot of business units are onboarding the solution now. We started with one and now we've got four or five business units we are supporting.

We have business users using the solution. For them, the usability is not 100 percent but it gives them some flexibility. They still have a problem: they may open an account for a customer but there are five different types of accounts. They have to ask for specific documents each time but they don't want to send the same document to the customer for five different accounts. There is some intelligence we cannot apply at the moment, such as finding which documents are already in the system and that we don't want to send to the client to fill out again. It is manual work as of now. The relationship manager will look into all the documents and say, "Okay, I already have this document from the client in the past couple of months so I won't send it again." Primarily, when we generate documents we don't apply intelligence to validate which documents we have. We don't analyze the data in the system; we keep generating documents.

I would rate FileNet at nine out of ten. All the capabilities I needed in setting up documents or applying security, using content and filters, met the requirements that we had for the solution.

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.

There are two use cases. One is as an extended datastore for IBM Connections, but we don't have many Connections customers. We have actually lost two such customers in the recent years because IBM didn't do anything for that product. 

The more common use case is as a general filestore for documents, with interfaces to the Web, etc. It is used to store incoming invoices and documents and to classify them. It's also used to automate the process of document storage, when documents come in. We have a mechanism to automatically categorize a document based on content. Based on that, we are able to create attributes for the content management system. Then we store the document in FileNet to enable retrieving it. We have PIDs, a universal access code, for each document and via that we are able to retrieve documents, even via applications.

We have created some interfaces. We have a central solution to make it easy for customers to plug in their application systems in an easy, customizable way, without having to program it. We also work in the area of analytics where we use Cognos. We have customers who retrieve information about incoming invoices. They can click on a link and retrieve it automatically out of FileNet or Content Manager.

FileNet helps increase productivity. For example, in reporting for a construction company, when they look at the costs, they can see the incoming and outgoing invoices. By clicking, they pull that document from the content store. The productivity comes from not having to go to a folder and look for a document. It's the integration which makes it productive, day-to-day.

You can only see how much the solution saves when you did not have a content system before. We have customers, for instance, who stored their documents in PDF format in folder structures. They had structures based on year and customer number. To find and use a document would take three to four times more effort than to have access via automated interfaces. The next gain is when you plug in mobile. Then you need something like FileNet, an intelligent content store.

It also helps with compliance and governance issues because it's a datastore that is not modifiable, and you can guarantee that. You cannot guarantee that with a folder-based file structure, where multiple people have access. In that scenario, you cannot guarantee that a document hasn't been changed.

The most valuable features of FileNet are the 

• storage mechanism
• search mechanism 
• interface through Content Navigator and 
• mobile interfaces. 

The area of migrations to new versions must be made easier. It's quite good that they have now begun to improve the API area, to modernize the interfaces, but there's always a very big investment involved in migrating from one version to another. That prohibits rolling out new functionalities to customers. It's not so easy. You can't release a new version every three months to bring in new capabilities. That is the old-fashioned, the way it worked ten or 20 years ago. That is bad. In that area, they really must improve.

We have FileNet, Content Manager, and TSM in our own installation. We migrated that installation three years ago to version 5.12. Now we have to migrate to 5.25 to bring in new facilities, and it's a big task. We have to do it in addition to our other tasks where we support customers. We need a parallel machine and to set it up there and to migrate step-by-step, then test it and roll it out. It's not so easy. That is a big area where there is much to be done to satisfy the needs of customers.

I've been using it a long time. We have been an IBM Business Partner for more than 20 years. We have been using FileNet since IBM bought it, I believe about eight years ago. We have been in the content management area since 2002. We started in the area of content systems with IBM Content Manager and then we added our support for File Net.

I have never really heard of problems with the stability because the database. IBM Db2 is never a problem. I cannot say anything about Oracle or other databases. We have avoided implementing with a non-IBM database where we can. When we do, there is no problem with stability.

In the larger installations, we use primarily TSM as the object store, and therefore we do not have problems with overrunning file space and those kinds of issues. The only thing we have seen is that when a customer's system administrator installs a new Java version on the server where FileNet is running, sometimes it can cause a big mess. FileNet doesn't come up.

We have customers with a very small user base, 50 users or so, and we have some who have a really big user base. But the scalability is primarily dependent on how long you are storing documents. The time over which documents are stored now has been extended far beyond seven years. In the past, often this was a financial necessity. But now, even though we do not have insurance companies as clients, we have customers where the stored documents are more than ten or 15 years old. The scalability is also more dependent on the count of documents than on the user-base interaction.

From my point of view, it's scalable enough. Today there are machines which are scalable, where you can put in additional processors and memory. In today's scenarios, scalability is not really an issue. FileNet can take advantage of today's technology for scaling. There are other products which cannot because the database prohibits it. When they use MS SQL Server Express, for example, there are limitations. And when you have windream and such solutions in the German market, which are also in the Austrian customer area, they show wonderful functionality and a wonderful GUI, but when it comes to the extensibility and scalability, they reach their limits relatively early.

We have not had to use technical support very often. We get technical support from Germany. There is a good support center where the response time is quite good.

When you use IBM Content Foundation as the entry point for installation, it's quite well-documented. If you have know-how in the IBM area, including the area of WebSphere Application Server, then it's not too hard to install. It's up to your partner to download the right versions which fit together, the right way, and then it's not really a big deal. In those circumstances, you can install FileNet within two or three days and have a running version.

Process automation is the main reason we created our own server: To make the interfaces easy and to automate the process of storing and adding the right attributes, and to make sure you're able to search and find the document again.

It's very hard to say what the ROI is on that automation. The goal was to make a solution for the customer where he can solve his problems. For us, the greatest part is the services part. We set it up as a vehicle through which customers are able to implement automation, and to make it easy for them to apply it to their applications.

For FileNet in general, the return in investment happens over two to three years when you take into account the license costs, the maintenance costs, and the implementation. I think that is a reasonable ROI. I have heard of products that have much longer ROI.

The licensing cost of FileNet is comparable. It costs more if you use Case Foundation or the like — if you extended it. But that is not the scale of our customers. They are too small for that.

We do the scanning part, at the moment, with other products, not the IBM scanning engine, because it's a price-sensitive area.

The problem is that the competitors' products have, in most areas, a contract with an ERP system. We now have three customers who are migrating to new ERP systems and they all have contracts with a document management solution. They bring it in with a fixed price and give them a whole document integration path.

We have one customer who, for many years, used IBM Content Manager, and now he's migrating to a new ERP system and he's throwing out the old solution because, with the new ERP system, he has document management out-of-the-box with the licensing cost. This customer has no experience with the new document management system. Nothing. The ERP seller sold him the D3 DMS system and now we have lost that content management installation.

In terms of decision-making, the problem is that most customers have IT people making the decision about which product to use and they do not have really the experience. When customers come to us, they often come in with a prepared offer from someone else with a vested interest.

This is happening more or more and it is not good. In the past, it was up to the market to have a good but independent product with interfaces to all application areas. With this new scenario, it's the IT managers, who do not have much experience — they come from university from which they only have technical knowledge — and they say: "Okay, I have one supplier who is providing me one solution. I have an all-in service contract and I don't need to take care of the solution on a technical level." That is bad for independent solutions like FileNet.

It's a stable solution. It's proven. It provides guaranteed compliance; neither the attributes nor the content itself can be modified. You can guarantee and report that. The implementation time is no more than for other products. And the product is scalable.

In creating our tools we have integrated a lot with FileNet. It's very easy to integrate because the only thing you need is a mechanism to store, a way to add and change attributes, and to retrieve. You also have to be sure that you have a good search engine when you do not have direct attributes, a full content search.

In the first years, we were not happy with the usability of the content management products. Content Manager had no value for end-user interfaces. We passed on the strong demand for that. In the last few years, with the new versions of Content Navigator, it has been much better. We have a good interface also in Notes, in the right sidebar. It's a solution from IBM, Germany, where you can drag and drop documents. The Content Navigator now also has mobile support with a good interface. It's much more useful than it was before.

The internal features haven't changed and are enough to fulfill the requirements of customers. But customers always want a beautiful GUI. It's much more necessary to sell it with a beautiful GUI than with the functionality they really need. When we sell it, the end-user interface carries a much greater weight in customer decision-making than the technical part. On the technical side, there is nothing that FileNet is missing. There are three ways things can be stored: in the database, in the filestore, or in TSM. Our larger customers have TSM as object storage for FileNet and that is a very good solution.

We have not implemented the IBM Automation Platform for Digital Business. We have looked at it. We thought that in the last two or three years it was too big, too heavy, and too expensive for our customers. We are rethinking that at the moment, looking again to see if it can help and if it makes sense. We are not sure in the moment if this automation package is really a helpful and an effective investment.

Overall I would rate FileNet at nine out of ten. What it's missing to make it to a ten is the possibility of implementing new versions and new functions easily, in smaller time intervals, without a big investment on the customer's side. That is a barrier to new functionalities. In addition, IBM doesn't market well. You do not hear anything about FileNet in the market — nothing. Nobody has promoted it over the last three years. You hear much more about all other DMS systems compared to FileNet. You hear about new facilities, about mobility, and the integration of scanning and scanning-automation processes. You don't hear anything about FileNet. And that doesn't make it easy.

We're an IBM business partner. We work with customers who purchase IBM and we help them implement business solutions. Often times, we just influence their decisions. Most of the time FileNet is being used for automation projects.

An example is one of our customers, an insurance company. They didn't have process-automation before. We helped them implement an IBM product suite with FileNet content management with workflow and analytics. It helped that company reduce processing costs. It helped them unify processes in 21 countries where they have a presence, and they use it as an IT framework that helps them integrate other companies which they acquire. They're big on acquiring smaller organizations to help them grow.

Productivity gains come where workers can focus on more important tasks, higher-value tasks, and where the repetitive tasks are delegated to software.

In the end, almost every solution that we create for our customers helps reduce costs. In most instances the solution has saved time as well. Where we do get statistics from our clients, on average we see 20, 30, or 40 percent gains in terms of turnaround time. You can see that, for example, processing a complicated claim would have taken weeks and with the software solutions built on top of IBM software, sometimes it gets down to days or even hours.

It has improved business processes or case management for our customers. That's the primary purpose, that's the reason why they're investing in the software.

The most valuable features of FileNet are its comprehensive ability to store content, to get insights from the content, and to use that content for making decisions routed through workflow.

Nowadays, with the new capabilities, the unattended task processing - so-called robotics or digital employees, digital agents - is where this industry is heading.

I think it's to the point where there are probably too many features. Every software, as it matures and graduates, grows the list of features. What many of our customers express is that it's just too complicated. They're using maybe five or ten percent of the features but they're having to pay for 100 percent. There is room for improvement in terms of simplifying it. This is a case where sometimes less is more.

Making it easier to deploy, easier to use, easy to integrate are the biggest areas for improvement.

Every new software has bugs, but the FileNet software suite has been around for ages, so it's stable, it works.

The scalability is infinite if you know how to use it in your software products.

Technical support is very decent. We've never had issues with it.

The integration of this solution with other products is where we come in as consultants. IBM software works great in the silo, the silo being that you have an IBM software suite and everything is working together great. But when you have a customer that has IBM and three or four or five other repositories, a line of business systems that need to be integrated, that's where typically consultants, systems integrators like our company, come in.

But IBM provides a great API and ways to integrate the software.

ROI is hard to tell, it varies. Sometimes it's tangible where it can be measured in percentages from 10 to 15 to 20 or even 40 percent. Sometimes it's intangible, where companies can get ahead of the game, get ahead of the competition, and get their products to market faster.

I would advise a typical due-diligence process. Get hands-on with it, try it out. Do the same with competing products and decide what works the best.

Usability of the product is a complicated question. Anyway it is created, software cannot serve everybody's needs. Most of the time we'll work with very large companies and all of them have their unique needs. We oftentimes start with a base and customize it for each customer and their specific use case. You'll find a number of users that can use software out-of-the-box. But we often have to change it, tweak it, tune it, to tailor it to their specific environment.

FileNet is a nine out of ten. It's been around forever, it's stable, it's mature, it works. We know how to use it. We can confidently recommend it to customers without impacting our reputation.

As a systems integrator, for us, every customer is unique. In every environment there are very distinct challenges, so it's hard to take the knowledge from one client and apply it to another. Every time it's a journey. Sometimes there are technical issues we have to overcome. Oftentimes there are challenges, the business challenges that we help our customers overcome. The exciting part is that it's challenging. Challenges are always exciting, and that's what the software helps us with, overcoming challenges.

Very easily, the most valuable feature of FileNet is its reliability. We've been using FileNet Image Services since 1989. I average under one hour of unscheduled downtime per year. I have 800 million documents of patient records and patient financial information that reside on my box. It is sub-second response time and it just plain works.

It has done a significant number of changes. One, it has gotten us off of paper and it has also allowed us to streamline some of our work processes, so that we are electronically controlling those as opposed to doing them in the paper-pushing world.

The key to me is the ability for Watson and other analytic opportunities to be able to reach into the dark, unstructured narratives that are a key component of our medical record and read them, ingest them, and apply their analytic skills to them.

We will not have that until we complete the migration onto the FileNet P8 platform. Then, even then, we expect that there are going to be some significant challenges. I'm confident that IBM, which has very smart people, is going to be able to figure it out. That's absolutely something that I’m looking forward to them adding onto the solution; 100%.

The stability is second to none. We have consistently, year after year after year, been able to maintain an uptime of, I don't know how many nines it goes down to, but you can do the math; I have under one hour of unscheduled downtime per year.

The scalability is phenomenal. It just keeps growing. I've often likened FileNet to a teenager at an all-you-can-eat buffet, where you can just keep on feeding it and it'll keep eating and eating and eating. You'll run out of food long before the teenager stops eating.

We do use technical support. I'm a member of what IBM calls the AVP, Accelerated Value Program. They're phenomenal. These guys know their stuff. They are responsive. I have a wonderful and long term relationship with Peter Fagan, who is my AVP tech. I absolutely love the guys.

The initial setup was 1989. That perhaps predates many of us. I joined the firm in 1995, so I was not there for the initial set up. I've been there for, I believe, a representative period of time.

I’m involved in the decision process to continue making upgrades, absolutely. In fact, it's a very small team of very dedicated and focused folks who have all been with the firm for approximately 20 years like me. We don't have turnover and we don't want turnover in our product line.

From time to time, we do explore options. We looked at EMC's Documentum product, for example. We found that the migration to it was going to be as painful if not more painful as the migration onto FileNet P8, and was going to have the added detrimental aspect of bringing in an entirely new relationship. We were not confident, honestly, that the product line was going to survive for the long term.

When I’m selecting a vendor to work with, I need one with vision that is going to be able to stay with the course over the period as long as a decade. Things do not move necessarily at the speed of light. We need to know that a product line that we spend a year or two or three migrating onto, is going to be consistently available and enhanced over the next decade.

I'm not convinced that migrations can ever be made easy. I think migrations are a pill; you swallow it, it works its way through your plumbing and it comes out the other end. There are various times in the process when it hurts.

As far as building a solution in-house, I'm not sure that an enterprise content management solution is the kind of thing that is buildable in-house, though there are some who are perhaps arrogant enough to think that they can pull that off.

The key is to get involved in the user community, whether that means coming out and dedicating a week at a place like World of Watson or whether it means reaching out to a local user board if one exists local to you. The customers and the other users of the product line are sometimes more honest than one would expect a Salesforce representative to be. Get as much information as you can from people who are actually using the product.

We are not employing IBM on cloud, hybrid, or box solutions in the immediate short run.

We absolutely have plans to include mobile. We are hoping to allow our clinicians access to importing of documents or importing of photographs that are taken during the course of patient care and including them in the historical medical record.
As far as new analytics or content management services that we're now able to provide for our organization, we are in the process of migrating off of the Legacy Image Services product onto the new P8 product line. Once that is complete, we hope to be able to take advantage of some of the content search services and other bigger analytics that might become available at that point. Until we're there, I can't speak to that.

We've been on Image Services so long that I have to say no, there aren’t any existing services that we're now able to provide better than we were previously. Image Services is at the tail end of its life expectancy and all of our focus now is on moving onto the newer platform called FileNet P8.

Regarding how FileNet has changed the experience for our customers internal and external, there's no question that it has enhanced our ability to manage access to the medical record and to make it available both to our researchers and to the clinicians at the same time. Back when it was paper, it would be signed out of the library just like a book. With only one copy of it, if it was being used by a researcher, and Mrs. McGillicutty came in unexpectedly for an appointment, we had to track down where that record was and sometimes it led to delays. Now that it's all electronic, that's no longer a factor.

As far its usability, I have been using FileNet exclusively in my work environment since 1990. I'm very comfortable in it. I have found that it is a reliable, fairly simple, but somewhat niche product. We are confident that the P8 platform, while it is more open, is going to be as reliable, is ultimately going to be as usable when we move forward, and perhaps much more modern and able to take advantage of a lot of the newer tools, such as mobile, that really have not existed.

The older product line is phenomenal, but limited in what it can do. The newer product line is not sufficiently well known to us yet, but over the course of the migration, we will certainly learn a lot more about it.

We use IBM FileNet for content management purposes.

The application's processing engineer needs to be more advanced.

We have been using IBM FileNet for two years.

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

We have more than 500 IBM FileNet users in our organization. It is a scalable platform, and I rate the scalability a seven out of ten.

A third-party services vendor, a gold partner certified by IBM, helps us communicate with the technical support team.

We are working with many products for content management, including SharePoint.

Our team didn't encounter any difficulties in implementing the product. The installation process takes a week to complete, whereas it takes around six months to create the content. We have a team of four technical engineers to work on deployment.

We take assistance from a third-party vendor for implementation.

The product generates around 30% benefit.

The platform is inexpensive. I rate the pricing a seven out of ten.

The operations management team primarily utilizes IBM FileNet as the foundational tool for content management. It offers a range of modules with additional functionalities for tasks such as daily maintenance, yearly maintenance, and quarterly maintenance. It has broader capabilities, and the team has tailored its usage to meet specific content management needs.

The platform efficiently streamlines the handling of documents and content in our organization. It is a user-friendly system and easy to manage for anyone with basic knowledge.

It has been leveraged effectively in our existing workflow, particularly concerning third-party components and directory services.

The security features work effectively in managing sensitive information and ensuring confidentiality.

I rate it an eight out of ten.

On-premises

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.