|
Home |
Software Providers |
Consultants |
Articles |
Columns |
Reviews |
Headlines
|
|
|
- |
| - |
|
- |
Entire contents Copyright © 1999 Business Insurance "User friendly software; What to look for to actually measure
the useability of a RMIS"
|
|
USER FRIENDLINESS is a very often used -- but infrequently defined -- term that is important to any user of risk management information systems, or any computer system for that matter. Last month's column centered around the term's definition (BI, Sept. 21). Let's now examine how one quantifies a system's user friendliness. Rick Hoehne, president of Paradigm Infosystems in Bothell, Wash., will again offer his expertise on the topic. How does one determine which system is easier to use than others? With varying levels of computer literacy, people have different opinions on what is and what is not easy to use. In addition, the comprehensiveness of the system itself is a factor in how easy it is to use. Some systems deal only with one claim line while other systems are wider in scope, incorporating claims management, insurance management, underwriting and financial analysis. One module or function may be easier to use than others, or the relative skill of the person using the system may be stronger in one area than another. While the matter is largely subjective, there are certain essential quantifiers to look for when judging an RMIS' user friendliness. Each represents major steps or events in using any system. These are: Screen layout Obviously, this is the first thing one notices when looking at a new system. If the system is menu-driven like most are, is it logical and obvious to the user, whether a seasoned veteran or a novice to the risk/claims profession? The existence of icons to identify certain functions will greatly help, as I spoke of last month. An even friendlier screen would look like a paper form that is constantly being used internally by the department. For example, many systems' screens, like Paradigm's Paradisk, are laid out exactly like a First Report of Injury for a particular state. Also, are the screens presented in the same order that the user performs his/her job? If the process of entering a claim follows a specific format, the system ought to follow the same steps to avoid unnecessary screen changes and the need to look up data. These features all rely on the system's vendor. The system should be designed for the user, not from the convenience standpoint of the programmer. I often see this problem when I review proprietary systems: The programmer found it more logical from a systems programming perspective to design the screen and data-entry process in a certain fashion even though it wasn't optimally efficient for the user. Finally, does the screen layout help or assist the one monitoring or entering data? In other words, does the screen limit the input of data only to pertinent information, in order to prevent entering incorrect data? For example, if one is entering claims data on a workers compensation medical-only claim, the system should not accept data pertaining to indemnity claims. The other field should be temporarily disabled as a further prevention for incorrect data entry. Data entry, monitoring and manipulation The next area of importance is the ease of entering and accessing data. The system should reduce the need to rekey data in different screens and should provide quick exits from one screen to another when exceptions occur. In other words, does the system have pop-up or pull-down menus or other simple navigation devices for moving into different areas of a program? As a practical measure, the user should look at the six to 10 most common screens used in any system -- like diary, claims entry, checkbook, reserves, provider list and report menu -- and ask the vendor if it is possible to move from screen to screen with only one entry. Or, how many keystrokes are required to move from one screen to another? In addition, how many keystrokes does it take to add a claim? How many screens are involved for this function? Are the screens jammed with information that is irrelevant or misleading? When claims information is entered, is it automatically included through the entire system to avoid repetitive data entry? It is here that most errors in data integrity occur. Reporting function This may be the most obvious quantifier of all because it is here that risk managers and senior managers see the bottom line or result from the information system. Again, the same questions apply: How many keystrokes does it take to provide a simple ad hoc report consisting of claim number, claimant name, date of loss, location, total paid, total incurred, subtotal by location, etc.? More importantly, can the ad hoc report writer simply do it, or will the vendor answer with, ''Oh, we have that as a canned report -- no problem.'' This answer is not acceptable. A true test of how easy a reporting function is to use is its ability to intuitively construct a report with a minimum of keystrokes and screens. The report should be accurate, logically laid out -- i.e., no computer operating system garbage -- and have readily accessible and easy-to-understand graphics support. In fact, you may have several different report formats in mind as you review the system or have the vendor demonstrate how to construct the report. Another crucial area is the ability of the reporting package to combine typical data base information, like lists of certain claim parameters, with word processing and analytical applications. Most systems with canned or developed report writers have difficulty seamlessly integrating those three functions. Special operating system codes must be written to perform these functions, according to Paradigm's Mr. Hoehne. However, in the McIntosh environment or Microsoft Corp.'s proposed Windows NT program, the applications software -- data base, spreadsheet, word processing, etc. -- are embedded within the operating system and hardware to allow total flexibility. Therefore, reports can contain summary lists, analytical fields and custom-typed letters as the need arises without leaving the application and going into an operating language like DOS. Help screens Help screens should be available from anyplace in the system. Mcintosh-related systems have balloon help boxes. Anyone familiar with the Windows environment knows that help screens are instantly accessible. Once the key features have been identified, the next step is to quantify the user friendliness of a system. The RMIS evaluation can be as simple or as complex as necessary. The end user could construct a matrix identifying each of the key features involved, assign them weighted values of importance and numerically assign values of 1 (poor) through 10 (excellent) on each of these features. Or, one could simply tick off on a yes/no basis each of the key areas of greatest importance. The basic recommendation here is to perform the analysis up front to save headaches in the future. It bears reminding, though, that user friendliness still is quite relative. To a computer software engineer, some of the above criteria are not as important as they are to the occasional PC user or neophyte system user. The risk management professional must judge what degree of user friendliness is needed for the task at hand. For example, an insurer or a TPA about ready to commit to a very large system installation must consider the relative impact of user friendliness for the majority of those who will be working with the system: inexperienced clerical individuals. If the risk manager will be the only one using the system, only he or she can judge what's easy to use and what isn't. Secondly, RMIS vendors are recognizing the importance of user friendliness in marketing the systems. Indeed, even some of the older, more established system vendors in the mainframe environment -- such as Risk Sciences Group Inc. in Atlanta and Corporate Systems Ltd. of Amarillo, Texas -- are providing user friendly front-end applications to make things easier for their clients. This was a good step in the right direction. However, Mr. Hoehne says, ''In the end, you and you alone will be the judge of user friendliness. In evaluating this, it is best to apply good, old-fashioned common sense.'' Furthermore, ''The system vendor must design for the rule, but plan for the exception,'' he added. I heartily agree. By applying the methodology discussed in the last two columns, a RMIS user can reduce some of the subjectivity involved in judging user friendliness and deciding, indeed, what is best for him or her. Copyright© 1992 Business Insurance |