Pharmaceutical Industry Overview

Posts Tagged ‘software vendors’

A look at providing some key tools for evaluating not only software applications, but the software vendors that build and support the applications to the research community.

Commercial software applications for research facilities have been available for over 25 years but have not been widely accepted or implemented until the last ten years or so. Looking back over the last decade, there have been many changes in technology and the ways that software companies develop software that have affected the quality, functionality and accessibility of applications designed for research facilities. Like the software itself, vendors have matured and evolved as a result of feedback from users, learning from mistakes and successes, and, in the case of some research applications, learning how to address government regulations. Recently, there has been much discussion in the research community through forums like COMPMED regarding which vendors and software applications will deliver the best solutions for medical research. This article is aimed at providing the research community with some key tools for evaluating not only software applications, but the software vendors that build and support the applications.

Know What You Need
The most important tip in selecting software for a research facility is to buy what your facility needs. Every facility is different and has specific goals they wish to achieve. Your requirements should be defined by what will make your organization more successful in realizing its mission. Satisfying operational needs like automating the IACUC process, tracking animal use, creating animal orders, automating communications and notifications, managing transgenic colonies, or maintaining animal records should justify and eventually pay for the investment in research software.

Before you start looking at the available software applications, it is important to put down on paper some very basic requirements that will define what would be acceptable for your facility. Consider the following questions for defining your requirements:

• What are the key processes in your facility that contribute to the success of your mission? Some key processes might include IACUC protocol creation, submission, review, approval, and lifecycle management; animal ordering; clinical information management, etc.

• What are the key processes that hinder the success of your mission? Are there key areas that if you automated them, would provide higher levels of compliance, better access to information, or reduce the risk to the facility?

• How are the most successful organizations, that are similar to yours, performing similar processes? In relationship to other industries, the research community is comparatively small, but diverse enough that you should easily be able to find a few facilities that are similar in size and mission, that you can contact by phone, e-mail or at an AALAS meeting to discuss what solutions they have for their processes.

• Can these processes be implemented in your facility? Can you change the existing processes or are you limited by regulations or policies?

• What other parts of your organization are influenced by, or contribute to the processes in your facility? For example, does your facility need information from the IACUC on protocols that have been approved? Does the animal ordering and animal usage information need to be returned to the IACUC or regulatory affairs staff? Can you make a list of all of the people/divisions/departments that will be affected by a software application?

An important part of defining the key processes in your facility is to diagram the information flow for each process, the roles of the people involved and the relationships between these processes. A simple example of this might include the flow of information inside of your IACUC (Figure 1).

These flow diagrams also give your facility an opportunity to review your processes and see if there are better ways to streamline the flow of information.

Once you have a broad understanding of what your facility’s processes and requirements are, you are prepared to begin reviewing specific requirements. There are many ways of collecting user requirements such as surveys, focus groups, interviews, direct observation, or scenario-building. Regardless of the method(s) chosen, it is important to define the difference between what is required in an application to meet your basic operational needs versus what is nice to have. Often, during requirements collection, end users want software to solve problems that are not best suited for software applications, or may not even be possible or feasible. Classifying what is necessary versus what is nice to have will help you in making an assessment of available applications.

Preparing a simple spreadsheet checklist of your requirements and giving it to the vendor to provide you with an evaluation of whether they can meet the requirement out of the box, meet the requirement with some modifications, or meet the requirement with new product development, is a quick way to evaluate which vendors can most closely match what you are looking for.

Know How It Is Built
In 1990 Tim Berners-Lee put together the first browser based software code at the Conseil Européen pour la Recherche Nucléaire (CERN) in Switzerland and the first web-site appeared on the World Wide Web. Since that day, software development has changed incredibly to the point that the average user is now used to logging in to browser based applications in order to enter and review information. But few people realize the depth and breadth, and sometimes the limitations of the technology that can be applied in building software applications. Often, end users make decisions about software because of the look or the visual appeal of the application and overlook key technology points that may affect the stability, support, and security of the application.

When evaluating software applications, there are really two aspects that should concern your organization: how the data is collected and how the data is stored. These are commonly referred to as the application interface and the application database, or more simply the application and the database. The technologies used to develop these two components vary, but are important to your organization.

Applications come in a variety of types, but most often they are defined as either client/server or native browser-based applications. Client/server simply means that a piece of software code is required to be installed on any computer that will be used to access the database, whereas native browser-based applications can be accessed via a web browser from any computer within your network. Traditional applications are client/server based whereas newer applications on the market tend to be native browser-based.

Whether you are considering client/server or native browser-based applications you should consult your Information Technology team to determine what level of support they will provide for you. In addition, the software application’s vendor should be willing to share with you the details of the tools that were used to develop the application. Research on these tools will reveal whether your vendor is staying current with new technology or relying on tools that they feel comfortable with.

The database is actually of more concern to information technology staff as that is where the greatest risks exist to your organization in regards to data integrity, access to information, and security. There are several types of commercial databases available to developers. These range from simple, flat form databases that are non-relational (simple files that can be accessed for data storage and retrieval, but do not have relationships with other data files or tables) to relational databases like Access, 4D, and FoxPro that are designed for single or a very small number of users on a network, to commercial enterprise databases such as Oracle, MS/SQL Server, Pervasive, or Sybase. This last generation of databases is typically used for applications that will be shared by multiple users over a network. Examples include financial applications, enterprise resource planning applications, and facility management applications.

Each of these types of databases has different levels of security and data integrity protections built in. The first class of databases is rarely found in research software. The second generation tends to be used for smaller facilities with few users, while the last are typically used in medium to large commercial, government, and educational institutions. The largest difference between these databases beyond security and data integrity is the cost of licensing. This is typically not included in the purchase of research applications, so be sure to ask your Information Technology team and your vendor about this.

Know Your Vendor
You are most likely looking for a software application that will support your facility for many years to come, rather than something that you only need for a short timeframe. So selection of your vendor is as important, if not more important, than the selection of the software itself. If you are looking for an application that will support your many processes and departments in your organization, you should consider your vendor as a partner in your research. As with any partnership, careful consideration should be made in the character, quality, and commitment of your vendor. You should feel comfortable with the relationship and know that you can ask questions not only about the vendor’s products and the support of the products, but also about the company itself. Your vendor’s role is to give you the level of comfort you need, to know that their mission of supporting research is aligned with your core mission of conducting research. During your due diligence of evaluating software applications and vendors, consider asking potential vendors for information on topics such as:

• Company size and structure. Ask for an organizational chart which lists not just roles and titles, but names of individuals in these roles. This information is confidential to the company, but if you have exercised a mutual non-disclosure agreement, they should be comfortable sharing this with you. Evaluate the division of labor within the company. Of key importance are the ratio of staff that are in research, development, testing, and support of products to the administrative, sales, and marketing staff. As a long term partner, you should want the majority of the company’s staff to be focused on delivering and supporting the applications that you will be using.

• Product Offerings. Is your vendor’s primary business developing and supporting software for this industry, or is this one of many product offerings they have? This is important to understand when it comes to allocation of resources for development and support activities. If there is a more profitable use of resources for another industry product offering, the vendor may not maintain the same level of service that you expect over time.

• Service Offerings. What services are offered to support the applications that you are considering? Services that may be important to you include product support, maintenance, upgrades, implementation support, training, and technical support for database or hardware issues. Other services that may be available include business process reviews, process consulting, project management, and staff augmentation. These may be valuable services that can help you implement the software more effectively. Ask for descriptions and published policies on these services, as well as any recurring costs or services not covered under the proposed solution(s).

• Financial viability. How long has the company been in business? Who owns the company? Is it a private or public enterprise? Public companies are required to file financial statements and annual reports which will give you an idea of their long term longevity and the amount of resources they apply to the products and services that they are offering to you. Private companies do not usually share this level of detail, but should provide a statement of assurance, a debt ratio, and a general financial statement of the “health” of the company.

• Experience in the research industry. Software developers are key to software development; however, it is rare to find software developers that also have experience with activities within the vivarium. Analysts, designers, and management team members that have worked in a vivarium or have had experience with the activities that you are hoping to streamline with software are key to delivering software applications that are pertinent to your business.

• Knowledge and processes that support regulatory compliance. Whether you are regulated by the USDA, FDA, OLAW, CCAC, Home Office, or other regulatory agency you have some requirements that govern your processes which the vendor will need to understand. Ask questions about specific activities within the vendor organization that support these regulations. For example, if you are regulated by the FDA, you may have requirements for a software application to be GLP compliant. Your vendor should be able to disclose to you the activities within their organization that support your mission with this requirement. Ask your vendor if you can conduct a vendor quality assurance audit of their facility to make sure that they comply with your own policies and regulations for the development of software in research. This audit should include reviews of applicable SOPs maintained by the vendor and a check to verify that they comply with the SOPs, a review of the curriculum vitae of staff to ensure that they are qualified for the roles they fill, and evaluation of key documents such as a Development Methodology, Quality Manual, and other information that will give you peace of mind that the vendor understands what is required to help you meet your own regulatory mandates.

• Experience and certifications in the technologies that the company uses. There are many software development languages available to developers today. There are also many choices in how data can be stored and accessed. It is important to ask the vendor about their experience and any certifications with the technologies being used for the applications you are considering.

Know Your Limitations
There is a general rule in software, as in many areas of business, known as the 80/20 rule. A commercial application should be able to address 80% of your facility’s requirements out of the box, while the other 20% can be addressed by custom development with the vendor, changes in your business processes, or via other means. While a list of software requirements may tell you whether an application meets this 80/20 rule, most organizations forget to evaluate the vendor the same way. Preparing a spreadsheet with vendor specific questions and responses, should help decipher what can and cannot be met by the vendor and give you a tool to determine whether the vendor is a right match as well as the software.

In your hunt for applications that will meet your business needs, it is important to remember that technology may not solve all of your business challenges today, but changes in technology continue to offer more and more solutions. Your selection of a vendor should include an evaluation of the vendor’s corporate long-term strategy with an understanding of their vision of meeting the requirements of the research industry. Ask yourself the following question: Will my vendor’s limitations be my limitations, or will my vendor work with me to use new technologies to solve my challenges?

Conclusion
There have been many changes in technology in the last decade, changes that should affect the software applications that you use to manage your research facility operations and scientific data. Putting aside past experiences and perceptions, research facilities can use some simple tools to evaluate vendors and applications designed for research to determine the best solutions available today and for the future.

Source