Tips for Choosing I & R Software

What should you look for in I & R Software?

Deciding which I & R Software System to purchase for your organization is a difficult task, considering the variety of software choices and the multitude of features available in each system.

The software choice you make for your agency determines the quality of your organization's services for many years to come. From service referrals to the creation of directories and statistical reports, good software makes all the difference in the world.

Software vendor's are always asked these questions:

  • "Why should I choose your software over the other options?"
  • "How does your software compare to this other vendor's system?"
  • "Can you give me a comparison chart of the different systems?"

Unfortunately, there are no available up-to-date, independent, comprehensive comparisons of the different I & R software systems. Furthermore, a comparison is only valid for the tested versions of the vendor's software at the time of the analysis. Some vendor's software evolves rapidly while other's stay fairly static. *A comprehensive, informative, ongoing analysis process is not in place in the I & R community.

How can an I & R organization looking for software make a good decision?

Let's start with the obvious . . .

1. Does the vendor have a large I & R software customer base?

There are only a few established I & R software vendors whose primary customer base are Information & Referral organizations. *Most vendors core software product ARE NOT Information and Referral.* Their core products are HMIS, Workforce, Funding or some other human service software. Be wary, these vendors have the least sophisticated I & R systems.

2. Ask the major I & R organizations what they are using and why.

Many of the well known and established Information & Referral organizations in the country have completed a comprehensive analysis process when choosing their current system. Give them a call.

3. If you have narrowed it down to a couple of I & R software systems, ask each vendors for a list of I & R organizations who have recently converted from the other system to their system.

This will tell you a lot about the a vendor's system. If the vendor has not converted customers from the other system to theirs, *Watch Out*.

4. If your I & R organization is in a particular field of I & R such as Aging or 2-1-1, ask the vendor for a list of well known organizations in the same field using their software.

If your organization is or is soon to become a 2-1-1 then find out what software the established 2-1-1 organizations are using, such as the United Way of Connecticut, United Way of Atlanta, or the United Way of the Texas Gulf Coast.

5. Look at the technology behind the software - what is the development platform and what database systems are used?

The software industry is a rapidly evolving environment, especially when it relates to the operating systems on your computers. Unless the software is written in a current development platform, you will be buying instant obsolescence. For example, if you are considering a FoxPro based system then you are considering a system that is 8 years behind the technological curve.

6. How often does the vendor release a major update? Not just a new version number but a major upgrade including a newer development platform.

This relates to #4 as well. Is the vendor staying on top of the ever changing software programming and operating systems environments that take advantage of new technologies?

7. The choice of software will have a huge impact on the quality of your I & R service. Be sure to involve the people who will be actually using the software when making a final decision.

There seems to be an alarming trend that vendors are pitching the merits of their software to upper level management and IT staff who have little or no experience using I & R software. The best resource for selecting a system is the group of people who use the software; Call Specialist and Resource Maintenance staff. Be sure to involve them in the decision making process.

8. Here is a commonsense tip that is relevant to all small niche businesses, including software companies: If the vendor offers fancy advertisement materials, has a big fancy office facility, and lots of employees; remember, you will be paying for that overhead.

The I & R industry is unique because the customer base is primarily non-profits, which means funding is limited compared to the for-profit world. We as software vendors have a choice to make:* Do we invest in our software or do we pay for fancy offices and promotional materials? *(At RTM we invest in the software).

9. This is a WARNING! Vendors will only show you the good stuff during a demo.

All vendors want you to buy their software. In order to convince you that their software is best for your organization, they will stay away from the areas in their software that are "less than optimal". *There is no way a one or two hour demo is enough time to fully evaluate a system.* Don't be fooled by the flash, study the functionality in depth.

Now let's look at the technical side of I & R software . . .

* * Note from Ed Toomey * * Software System Manager - RTM Designs

I would like to clarify that the following section is based on three opinions:

  • My opinion (Ed Toomey at RTM Designs)
  • The opinion of the majority of our customer base
  • The opinions from various people in the I & R industry

Besides being the head of the software development department at RTM Designs, it is my job to fully understand the features and functions of the competition's I & R software. With this knowledge we make sure our products are the most advanced in the I & R industry.

Web-based or Windows-Based I & R Software

I & R software falls into two camps: Web-based and Windows-based.

The primary misconception regarding these two platforms is Windows software is not available over the Internet and Web-based system are only available from the Internet. In fact, both systems are available over the Internet and both systems can be run in-house, off the Internet

In today's I & R software market the functionality differences between the Windows and Web-based systems is simply this: In terms of pure functionality, the Window-based systems are significantly more feature rich than the Web-based systems.

There are multiple reasons the Windows software is more feature rich:

  • Developing software using Window-based development tools is, by some estimates, five times easier than developing a similar system for the web. We have found this to be true at RTM Designs, even with Microsoft's latest web development platforms.
  • Windows was designed specifically to be a business application platform, the Web was originally designed as a document feeder which makes it less than an ideal business software platform.
  • Web systems, in some cases, are graphics heavy therefore restricting vitally important screen real estate for system actual functionality.
  • Windows systems can have multiple pages open at the same time and controlling screen maneuvering is easier to accomplish. A Web-based system can only have one page open at a time in a single Web Browser therefore restricting functionality.
  • Maneuvering from screen to screen in a Windows system is almost instantaneous while maneuvering between web pages is slow.

Call Processing Ability:

Performing a side-by-side speed test comparison of three popular Windows I & R applications against two well known Web I & R applications, processing identical, simple call transactions, including call statistics, this was the result. Processing identical call transactions, it took between 2.5 and 4 minutes for the Windows applications and almost 6 minutes for one Web I & R system and 8 minutes for the other.

Processing an identical, complex call transaction with multiple clients with different needs, recording the needed call statistics and notes, only RTM Designs software could process the call in one transaction, taking 7 minutes. All other systems, Window and Web-based required two call transactions, which immediately causes an inflated and inaccurate call count. The other Windows systems took 11 and 13 minutes to complete the calls and the web systems took 17 and 20 minutes.

In terms of productivity, Windows systems are more cost effective to run and maintain, even considering the staff time required to maintain an in-house Windows I & R system. The Web I & R systems, while not needing IT staff to maintain (the Web system are generally hosted by the vendor) will require additional people to staff a busy call center. Financially the Web systems will be considerably more costly to run on an annual basis, and less productive.

Summary:

The current crop of I & R Web applications were built using older development platforms (as are are several of the Windows applications). In 2006, Web applications should be using AJAX-like technology which doesn't require the web page to refresh after each submission. Here is a simple test when evaluating I & R web applications:

When submitting a request on a web page such, as clicking a submit or go button, or while searching for a client or searching the Taxonomy, if the web page refreshes (goes away and comes back) then the web site is using older technology.

While there is no doubt the Web may be the platform of choice in the future, today's Web-based I & R applications are simplistic, arduous, and time consuming to use and offer very few advanced I & R features.

RTM Designs Position:

RTM Designs has always offered Window-based I & R systems for in-house use at a customer's call center, primarily because Windows-based I & R systems can be developed, modified and completely updated in a fraction of the time it takes to create a comparable Web-based I & R application.

The end result is three-fold:

  • The I & R software is significantly more feature-rich
  • Cost and time of development and updating is reduced
  • The software is less expensive for the customer

Windows I & R applications have been the #1 selling software since the early 1990s.

All RTM Designs software system are accessible over the Internet, we choose to use something other than a web browser to provide access to the software. This tool is the Remote Desktop Connection which is standard on all current Microsoft operating systems.

While there is a definite market for Web-based I & R applications, the decision at RTM Designs was to wait until technology improved before investing in the development of a fully functional Web-based I & R software package. That time arrived in late 2005 with the advent of Microsoft's new Visual Studio.NET 2.0 (and upcoming 3.0 version) development platform.

This new platform virtually eliminates the need to refresh a web page. Web application will function more like Windows applications, but have the advantage of being accessible from a Web Browser. By late 2007, RTM Designs will have the most advanced Web-based I & R system on the market.

The new Microsoft Visual Studio.NET 2.0 and 3.0 platforms also promises significant improvements on all RTM Designs' Windows I & R applications, also due late 2007- early 2008.

ServiceSite Data Structure vs. Agency-Program Structure

The ServiceSite data structure is the design of the database that supports the I & R software. This structure defines the relationship between the agency (the service provider's parent location) and it's service delivery locations (Sites) as well as creating the relationship between the services and programs offered by the agency and how these services are "linked" to the appropriate site. At a minimum the ServiceSite data structure requires four levels of information: Agency, Site, Service Group (Program), and ServiceSite. Certain variations of the ServiceSite structure may involve up to six levels.

The Agency-Program data structure is also a database design used in other I & R software. This structure originated from I & R software development projects that would automate a service provider Rolodex.

This structure offers two levels of information, an Agency (Parent Location) record and a Program record (a combination of the service delivery location information and the services offered at that location).

How do the two structures compare?

Agency-Program Structure

From a simplistic viewpoint, the Agency-Program structure appears that it will meet the needs of a resource database. When entering a single location service provider with one or two "Programs", this is true. In fact it is just as easy in both structures.

But this is where the simplicity ends. When a complex service provider must be entered into a database, the Agency-Program structure gets overly complicated and redundant. An example will highlight the issue.

Suppose we have an agency that has four separate locations and each location offers four different types of service. When the data is entered into the Agency-Program structure the end result is seventeen records: One Agency record and sixteen "Program" records.

Each "Program" record contains a combination of location information (name, address, and phone numbers at minimum) and information about one of the types of service (Taxonomy Terms, Keywords, Eligibility, Fees Hours, Application Process, etc.). The location information is duplicated four times and each type of service is duplicated four times. (4 locations x 4 types of service = 16)

If any of the location information changes, it must be corrected in at least four "Program" records. If the information changes for one of the services (Programs), the data must be changed in four "Program" records.

Imagine what this would be like in the "Real World" when you have a service provider that administers 100 service locations (one in each county) and each location offers 3 to 5 different types of service (Programs). That's somewhere between 300 and 500 "Program" records to maintain.

ServiceSite Structure

Using the same example, one Agency, four locations and four types of service, a ServiceSite structure will create nine records. One Agency record, four Site records and four Service Group records. If any of the location (site) information changes, it is updated in one record. If a Service Group's information changes, it is updated in one record.

Using the Agency with 100 service locations and 3 to 5 types of service example, at maximum the ServiceSite structure will create 106 records (one Agency record, 100 Site records and 5 Service Group records)

Bottom Line - the ServiceSite structure requires much less resource maintenance.

Service Searching Accuracy

The ServiceSite structure offers exponentially better searching and display properties. While this topic is more geared for the "Techie-Types", it highlights a critical difference in the day-to-day performance of the two structures.

Starting with the Agency-Program structure, you may remember that this is a two level structure. While the Agency record in both structures offer little value to the caller who needs assistance, the "Program" record in the Agency-Program structure is the workhorse. This is were the vital service location and service information is stored.

In a single "Program" record there are three components:

  1. Service Delivery Location Info (name, address, phones and more)
  2. Service Information (Hours, fees, how to apply, who is eligible etc.)
  3. Search Terms used to locate the "Program" (Taxonomy terms or Keywords)

All search criteria information such as Area Served, special filters, age and gender restrictions are linked to the "Program".

Suppose the "Program" contains three services (as described by the selected Taxonomy or Keyword terms) and each service has a distinct service area? Service 1 serves the entire county, service 2 serves only one city, and service 3 serves only three out of the six ZIP Codes in the city. The Area Served component can only be linked to the "Program" record, not to the individual services in the "Program" record. This is where the problem with accuracy starts.

Which service area should be linked to the "Program"? The county, the city, the ZIP Codes. How about all three? No matter which service area is selected, at minimum two of the services will be wrong. The service searches in your Call Center and on your public access Web site will be wrong. This will not be a good reflection on your organization.

What is the work-around for software using the Agency-Program structure?Only one, create individual "Program" records for the individual search terms. This will work but remember the duplication problem that you are already facing by using the Agency-Program structure in the first place. Multiply that by 100 and you will get an idea of what you are facing in order to maintain an accurately searched Agency-Program database.

Suppose one of the service in the "Program" is temporarily inactive, what's the option? Inactive the whole "Program" or leave it. Probably leave it and write a note and hope the Call Specialist sees it. Not very efficient.

There is a better way to search accurately

You guessed it, the ServiceSite structure. The Service Group record in the ServiceSite structure contains two pieces of information:

  1. Service Information (Hours, fees, how to apply, who is eligible etc.)

  2. Search Terms (Taxonomy terms or Keywords) used to locate the Service Group and the associated Site record.

Each service delivery location (Site) is linked directly to one or more of the services in the Service Group (depending on what services are offered at the particular Site). Each "Link" between one of the services in a Service Group and one of the Sites is called a "ServiceSite" record which means "one service at one site".

Each unique ServiceSite record contains the Area Served, age and gender, special filter, notes and status information for that one service at that one Site. Therefore when services offered by a particular service location (Site) each have unique criteria such as service area restrictions, it's not problem because each ServiceSite record contains it's own data, independent of any other service offered at the Site. This is another reason the ServiceSite structure is the only way to go.

Now if you are a real gear-head, the next logical question would be, "Does this mean that settings have to be made for every single service in my database? That would be a lot of work". The easy answer is "Yes". All ServiceSite records will contain their own setting. This is where the software plays it's part. Any good I & R software will provider Global Update features for those records that share the same or similar information. In fact, well over 50% of the sites that offer services will share the same ServiceSite settings so the Global Update utilities will be very handy.

Summary:

From the simple standpoint of day-to-day resource data maintenance, the ServiceSite structure requires a fraction of the time and effort to maintain a comprehensive resource database as compared to the Agency-Program structure.

The ServiceSite structure also provides better service searching accuracy than any other I & R database structure.

But this is not where the benefits end. The multi-level structure also provides precise data extracts and more concise and smaller printed directories.

The Service Site data structure is the only database format that can fully support advanced I & R functionality and is endorsed by sophisticated I & R organizations as well as knowledgeable I & R software developers. The ServiceSite structure is also the structure selected for the AIRS XML Data Transfer standard.

Why would a software vendor use anything other than the ServiceSite data structure for their database design?

In all fairness to I & R software developers, programming a software system to utilize a ServiceSite data structure is difficult and complicated. While the benefits of this structure are significant for the end-user. The result is an easier to use and maintain application. The vendor must have the expertise and be willing to invest significantly more time and effort in order to take full advantage of this structure.

How can you tell if a vendor is using a the ServiceSite data structure for their database design?

If the I & R software is an RTM Designs product, the software is using the ServiceSite data structure.

All other I & R systems use some variation of the Agency-Program structure.

The Database structure is the foundation of any information data driven software system. Selecting software with the correct structure greatly enhances the users capabilities and ensures unsurpassed functionality, now and into the future.

AIRS/INFO LINE Taxonomy

The AIRS/INFO LINE Taxonomy of Human Services is recognized as the national standard service classification system. Most of the viable I & R software systems have already integrated the taxonomy into their software packages eliminating the need for unstructured or non-standard "Keyword" systems.

The Alliance of Information & Referral Systems (AIRS) has established 21 points for implementing the taxonomy in an I & R System. Certainly all I & R systems should support these points, but there are intuitive methods and cumbersome methods of implementation. Review all systems carefully and compare how the developers chose to address the 21 points.

Things to think about when comparing Taxonomy functionality in an I & R software system:

  • The Taxonomy Hierarchy is a wonderful classification structure but, without a doubt, is the least effective searching tool that can be used used in the Call Center software or on a public access web site. If an I & R software system displays the entire Taxonomy hierarchy as a search method (going up and down the branch), you can be sure that this software vendor little experience implementing the Taxonomy in a software system. The Taxonomy Hierarchy has value only as a service classification structure tool for use in in the resource maintenance section of the software, not in the call center.
  • A Taxonomy term should only be displayed in the call/contacts module (or on a public access web-site) if it is directly linked to a service provider. This function should be fully automated, not requiring resource staff to inactivate Taxonomy terms.
  • Creating new Taxonomy Terms by combining two or more terms is a critical feature for an I & R software system. This function greatly improves that accessibility of resources to the call specialist and users of your public access web-site.

    For example: Combining the Taxonomy target term "Battered Women" to the Taxonomy service term "Mutual Support Groups" creates the new service term "Mutual Support Groups for Battered Women".

    This new service term directs the software user to the exact resources offering this special service without having to search through a large list of "Mutual Support Groups" or services for "Battered Women".

    This feature is only found in RTM Designs software and the PRISM system used by InfoLine of Los Angeles (originally developed by an RTM Designs staff member).

  • The software must have the ability to seamlessly and simultaneously search Taxonomy terms and the "Use Terms" library. The "Use Terms" library directs users to the correct Taxonomy term.
  • Be sure the software has the ability to add your own "Use Terms" and "See Also" references to the Taxonomy. This is important for enhancing your system's ability to locate Taxonomy terms with "common or familiar" terms used in your community.
  • The software should allow "Virtual Use and See Also term" searches.
  • The software must be capable of allowing the user to rename Taxonomy terms without changing the original AIRS INFO LINE term. The "Use Term" and "See Also" terms linked to the original term must also be linked to the renamed term. This function is critical for continuity with future Taxonomy releases.
  • The software must not force call specialists to search through all Taxonomy terms, or even just the active terms. When searching the taxonomy to make referrals, the call specialist should only encounter Taxonomy terms linked to one or more service providers. There is no reason to display taxonomy terms (active or inactive) if the term is not linked to a service provider and cannot be used for referrals.
  • The software must offer a Taxonomy Update tool that allow the user (not the vendor) to update their Taxonomy system whenever the AIRS/Taxonomy web site offers an update. This update tool should also replace old Taxonomy terms in previous (historical) call records with the new terms

These nine features are just some of the basic Taxonomy requirements for a sound computerized I & R system. There may be other factors that you may want to consider when evaluating software, such as your preferences for user interface. Take the time to look deep into the system's Taxonomy functionality. Avoid the "quick, first impression".

RTM Designs Position

The Taxonomy was one of the first standard required by AIRS. All RTM Designs software utilizes the Taxonomy and utilizes it well.

For the longest time, the Taxonomy has been scorned as being "Too Complicated", "Too Difficult to use" and "Too Restrictive". This reputation comes from users of other vendor's software. It's quite obvious that the majority of I & R software vendors take little time or have little experience properly implementing the Taxonomy in an I & R software system.

If you are considering or using a non-RTM Designs I & R software product, then you will find this to be true. Implementing the Taxonomy in an I & R system is very complicated. In our opinion, most I & R software vendors do not have the expertise or ability to take full advantage of the feature available in the Taxonomy.

In a recent examination of one self-proclaimed "State of the Art" web-based I & R system, this system didn't offer a "Use Term" search feature. This is a basic Taxonomy function that is critical in the call center and on public access web sites.

Simply stated, there is no I & R software system that can match the Taxonomy capabilities found in all RTM Designs software.

AIRS XML Capability

Several years ago AIRS embarked on a project that would hopefully provide a vehicle for the different I & R software system to share resource data regardless of the I & R software's data structure. From this project came the AIRS XML Data Transfer protocol. The current AIRS XML Transfer protocol is based on the ServiceSite data structure, which by the way was the best possible choice.

Approximately four years ago, four I & R software vendors were paid $4000.00 each by the United Ways of Michigan to implement import and export utilities in their software system (RTM Designs was one of the four) using the AIRS XML Transfer protocol with the stipulation that the functionality be finished within six months of receiving payment.

When evaluating I & R software systems, be sure to have each vendor display how the user's of their software can import and export data using the AIRS XML transfer protocol.

RTM Designs Position

It's RTM Designs opinion that the AIRS XML Data Transfer protocol is a marvelous tool. In the near future all RTM Designs software will use this protocol as the sole importing and exporting tool for resource data.

RTM Designs was also the first and only vendor to offer a user operated AIRS XML importing and exporting feature in the software within the agreed time frame of six months. It is also the opinion of RTM Designs that as of this writing (8/4/2006), no other I & R software vendor offers a user operated AIRS XML Data Transfer import and export utility. (One has to wonder if these vendors returned the $4000.00 to the United Ways of Michigan).

RTM Designs has studied and experimented with the XML protocol since it's inception in order to validate the possibility of having a successful exchange of data from another non-RTM Designs software systems.

When possible, RTM Designs would downloaded XML data dumps from the XML committee's web site in order to test the XML import functionality. In other cases RTM Designs had to develop XML data export utilities for other I & R software systems when an export (data dump) wasn't available.

As of this writing, RTM Designs has experimented with exports from IRis, Resource House, Service Point, Tapestry as well as our own software systems.

With the exception of importing data from another RTM Designs system, results weren't promising.

Due to the vastly different data structures utilized by the various I & R software vendors, it is virtually impossible to import data from another vendor's software without seriously compromising the integrity of the destination database (the destination database in this case being an RTM Designs ServiceSite database).

Inversely, importing data into an Agency-Program database from a ServiceSite structured database resulted in a loss of critical data items. Once again the integrity of the destination database was compromised.

Further testing revealed more obstacles.

  1. The differences in geographic systems employed by the various I & R software vendors made accurate Area Served translation impossible to reconstruct. Some vendors offer "User-defined" geographic systems or have no structured Area Served searching component therefore leaving it to the whim of each user to use or not to use some sort of geo searching functionality. This will also make it impossible for a vendor to accurately exchange data between their own systems.

    The merged database will be riddled with False Negative and False Positive search results.

  2. Taxonomy Level Coding differences provide another obstacle when merging data, Once again, for most I & R systems merging data, the service search quality will suffer. This problem is has more to do with the differences in resource maintenance practices at the individual I & R organizations than with the data structure. While RTM Designs software ors the "Virtual Term" search methodology which minimizes theffe negative impact of a merged double indexed database, all other I & R system don't offer this feature.

  3. Missing Data is another major issue when import data form a dissimilar database structure, as found when importing data from an Agency-Program database into a ServiceSite database. In simple terms, an Agency-Program database offer two levels of data (Agency and Program). A ServiceSite database requires four levels of data. Where are the two other data levels?

    Importing of data from a ServiceSite database into an Agency-Program database requires putting four levels of data into two. The only option in this case is to exclude data - not a good idea.