EPSS Tomorrow
Stanley E. Malcolm, Ph.D.
(Published as "Where EPSS will go from here" in Training, March, 1998, pp. 64-69)
The electronic performance support system (EPSS) point of view has been revolutionary. Its significance was how it re-framed our thinking from the training paradigm of "fill ‘em up with knowledge and skills and then put ‘em to work". EPSS practitioners and our business sponsors came to understand that people could be put on task far sooner - almost from day-one - if we provided an appropriate suite of integrated supports in the context of performing real-work tasks.
Understanding the EPSS vision remains far from common. Indeed, misunderstanding of the EPSS vision is far more common - a result, in part, of misapplication of the term by people who sought "currency" in being on the band wagon, despite the fact that they were selling traditional CBT, on-line reference materials, etc. Still, after roughly eight years since the phrase was coined, there are quite a few success stories for "true" performance support systems. What we call EPSS may change - there’s a movement to replace the term with "Performance Centered Systems," an attempt to recapture the original intent and to better appeal to the IS community - but the concept is here to stay, justified by the value these systems have provided to the visionary organizations that sponsored them.
While others struggle to understand and implement the current vision of EPSS, I think it’s time for today’s pioneers among us to begin looking ahead. Specifically, we need to ask what the EPSS of tomorrow should be like.
As I gaze into my crystal ball, I see future performance support systems differing in three fundamental ways from those of today. The EPSS of tomorrow will support groups, as they perform their various roles in a workflow, while content is being dynamically updated by users and environmental sensors. All of these approaches exist today - indeed have existed for years - but are rarely integrated into the same system. I believe that in the future they will be common, and integrated.
Groups:
Performance support systems today have been designed primarily for use by individuals: they support an individual as he or she works to accomplish some performance goal. On the commercial market, programs that help you prepare your income tax returns, write a will, or create a newsletter template all illustrate this level of support. Even less mainstream consumer applications like Parson’s Technology’s "Family Origins", a genealogical package, offer many forms of support. One of my favorites is a relationship calculator: select any two people in your family database and it will tell you how they are related. Another tool will calculate a person’s age in years, months, and days at marriage, death, or any other time in their life that you specify. In corporations, systems that support customer service representatives - whether in a call center for financial transactions or travel reservations, or face-to-face in the lobby of a hotel - also represent an individual’s use of an EPSS.
However, even in the earliest days of EPSS development there were cases that represented steps towards simultaneous use by groups. A case in point is the AMP Facilitator, a tool for business decision-making developed at Aetna, Inc. in the early 90’s. The AMP Facilitator stepped users through a rigorous analytical process that resulted in a business plan - complete with mission, CSFs, environmental scan, gap statements, objectives, action steps, and a strategy for implementation and monitoring. While the AMP Facilitator could be used by an individual, its preferred mode was in a small group setting. Imagine a group around a table with the means to project a computer display. The group would work through the steps of the process together, brainstorming, and receiving group processing advice from a built-in "coach." The work product belonged to the group and it was the group’s performance that had been enhanced by the EPSS.
Figure 1. The AMP Facilitator (20k) - A performance support tool for decision-making designed to accomodate small-group as well as individual use. Note the group process advice in the "Guide" pop-up.
Copyright Aetna, Inc., 1992. All rights reserved. Used with permission.
The AMP Facilitator only hints at the potential of EPSS applied in a group setting. To understand the full impact potential, you have to think of group use in the context of a workflow.
Workflow:
About four years ago, I began predicting that in the future EPSS would be applied to groups as well as to individuals. Believing that, I decided I needed to know more about "groupware" and signed myself up to attend a conference on the subject. When I arrived, I found that the field of groupware was converging on the study of workflow - in fact, the two fields had overlapping conferences and combined proceedings.
Why the merger? It was quite natural. Groupware covers a host of applications of technology to group work. In the early days of Groupware, emphasis was on technologies like bulletin boards, e-mail, meeting support, and group editing software - none of which implied much in the way of workflow. But these applications are not typical of how the "serious" work of corporations gets done.
In large corporations, most work is accomplished using business systems which imbed a process. In the insurance industry where I "grew up", typical business systems supported sales, underwriting, accounting, customer service, and claims processing. All these are heavily process-focused, but typically focused on performance of the process by individuals (e.g., sales people, underwriters, accountants, customer service representatives, and claims processors).
With the emergence of reengineering as a strategy for rethinking work processes, many corporations recognized that work could be performed more efficiently if it were "shared" with customers and suppliers, and between representatives of various functional disciplines. We began to see systems developed in which many people played a role in completing a task - according to a workflow reflecting a process that involved them all. The "system" extended well beyond the walls of the company that "owned" it. Take as an example an internet system for mail order delivery of goods. The task is initiated by a customer who completes an on-line order form and submits it to a distributor. The distributor processes the order and releases it to one or more suppliers for fulfillment. Key to the group nature of this approach is the fact that everyone involved remains in contact with the process, with access to the information that concerns them most. So, for instance, the customer can always "see" the status of their order; the distributor can "see" progress on fulfillment and generate roll-up statistics on suppliers’ performance, and suppliers can "see" those statistics that apply to them.
The groupware application with embedded workflow that I’ve just described cries out for performance support. The easiest case is made on behalf of the customer, who cannot be expected to take a course before ordering from a company’s catalog. Yet their purchasing decisions may need to be informed by a thorough analysis of multiple variables. Imagine, for instance, that the customer wishes to buy a photocopier. They have to chose among various features and balance all within a cost they can afford. Furthermore, they have to identify the copier among many that has the features they want, at a price they can afford, without the expense and complexity of features they will never use. A configuration "tool" would be the ideal support for such a customer. In fact, the prototype of such a tool - for the fictitious "Howell Copiers" - was included on an Authorware demonstration disk eight years ago.
Figure 2. Authorware EPSS Demonstration for "Howell Copiers" (62k) - An example of EPSS applied to a configuration problem where many variables must be weighed in order to reach a decision. Providing such functionality to customers allows them to take an active role in the purchasing workflow.
Copyright Macromedia, Inc. 1989. All rights reserved. Used with permission.
The Howell Copiers design remains one of the clearest examples of the value of EPSS for a "configuration problem" that I have ever seen. Of course supporting the customer is just a part of the solution in a workflow that involves distributors and suppliers as well. In the case of a groupware/workflow design, various performance supports would also be necessary for the distributor and for the suppliers. Look for such applications to emerge from the world of electronic commerce over extranets.
Dynamically Updated:
I’ve been outspokenly critical of the approach taken to most training design - specifically, the practice of instructional designers attempting to characterize their "audience" and then structure linear sequential content to match. It is as if the designer is saying, because the audience has these characteristics, this is what they need to learn, and this is the sequence in which they need to learn it. The fact is that designers can never really know their audience because it is made up of individuals - it is not composed of average learners. For those reasons, I’ve advocated designs that put control with individual learners, for it is only an individual who can know what they need to know, and decide what sequence of learning is best for them. (This can be done, and done well, but digresses from my point.)
Today I have to admit that I’ve been guilty of a similar hubris with regard to EPSS. I’ve assumed that performance support systems should be designed centrally, albeit with user input, in order to reflect business strategy and best practices. In other words, the system’s designers know best what users ought to do and what supports (knowledge, skills, advice) they need to do it. The result is a static model of EPSS - it gets designed and implemented, and doesn’t change until the designers determine that change is required (e.g., periodic maintenance projects).
Until now, we have taken a paternalistic approach to the design of performance support. It is about time for us to temper our designer-knows-best attitude. Our hubris is not in the best interests of system users, or the business sponsors of performance support systems. We need to recognize the unique vantage point of people who are performing the work - and provide them the means to affect our systems in a dynamic, yet structured manner. It is time for us to imagine systems where the locus of control for business information and "rules" is to some degree distributed.
Another way to look at this challenge is to say that yet another conceptual merger needs to take place - this time assimilating the discipline of "Knowledge Management", that is, capturing and sharing vital business information from a variety of sources, not just top-down, in order to enable better decision-making in a dynamic business environment.
Figure 3. Price Waterhouse knowledge management EPSS prototype developed by Internal & External Communication, Inc. (140k) - An example of a dynamically updated EPSS integrated within PW's groupware system for sharing critical business and personal development information. Copyright Price Waterhouse, Inc., 1997. All rights reserved. Used with permission.
I don’t pretend to have studied the field of knowledge management, but I feel the time is right to do so. We in the field of performance support have much to learn from it, just as those who study knowledge capture and sharing have much to learn from us about how to integrate various kinds of support into the context of performing work.
I must admit too that I don’t have a clear vision of how we can avoid anarchy in information capture. Too much information, of mixed or unknown quality, may be worse than no information at all - just look at the large number and mixed quality of "hits" returned on a typical internet search. A moderator’s role seems necessary, to be played by someone (or a team) with the experience to discard the chaff of bad ideas while propagating those ideas that are likely to bear fruit. Additionally, we might assign levels of "rights" to contribute based on individuals’ experience. Both approaches have flaws to be sure, but aren’t they better than designing systems that do not readily adapt to changing conditions - conditions best understood by employees out there in the trenches?
Before I’m accused of being unduly democratic, I should make it clear that I’m not suggesting that every aspect of an EPSS be open to manipulation by its users. Some areas should be strictly off-limits, for instance information related to compliance with law or regulatory bodies. Other areas might be altered after a period of informed review and something like consensus being achieved. An example might be changes in the underlying, embedded business process - something you would not wish to change without careful study of potential consequences.
While allowing people a greater, on-going role in shaping the knowledge embedded in performance support systems is one path to the goal of dynamically updated content, there is another I should mention: sensor technology. Paul Saffo of the Institute for the Future has written an excellent piece available at the IFTF’s web site. His title is: "Sensors: The Next Wave in Infotech Innovation. I urge you to read it at "http://www.iftf.org/sensors/sensors.html". While Paul speaks primarily about devices capable of processing information from the physical environment, I use the term more loosely to include probing our electronic environment. A common example would be periodically monitoring the price of a corporations’ stock - the one we work for, or one we may have invested in - and having that information presented to us or available on demand.
Using such electronic probes might allow us to design systems whose behavior changes depending on current values for variables external to the system itself - such as interest rates, stock prices, economic indices, inventories, competitor strategies as reflected in their prices, commissions, "specials", etc. For example, lets take the case of a customer service call center supported by an EPSS. The advice CSRs receive from the system on whether a customer is "valued" and should be retained if possible - or not - might vary with prevailing interest rates. A system that could vary directly without a designer’s intervention would enable a company to dynamically match its employees’ responses to the business strategy of the moment - not the week, the month, or the year. That my friends spells advantage and profit!
Taking the notion of sensors a step further, we might imagine "predictors." What I have in mind is data from business environmental sensors fed into a rule-based system in order to anticipate future trends. In this manner a company might be able to anticipate the future, changing its business strategy in advance of a changing business climate. Applying the concept to the CSR example above, the definition of a valued customer would be informed by a sense of how interest rates and other variables were likely to change in the future. A marginal customer today might become a valued one tomorrow - a customer your company should try to retain for the future.
Riding the EPSS wave has been great fun. With the potential for EPSS to evolve to be more supportive of groups, reflective of workflow, and dynamically variable, the field seems likely to stay interesting for quite some time. The key will be our capacity to grow and embrace new disciplines: groupware, workflow, knowledge management, environmental sensors, and sensor-informed "predictors."
Acknowledgements: The ideas expressed here have developed over time through a variety of experiences and communications with professional colleagues. Most recently, I’m grateful for the support of Malcolm Roberts of the Bank of Montreal for providing an opportunity to further develop these ideas and share them with his staff at the Institute for Learning. Thanks also to friends in the STEP and ALT-FS consortia, the Performance Support Systems Group, participants in the discussion forum at www.epss.com, speakers and sponsors of RMR Conferences’ 3rd Annual Performance Support conference, and former staff of the Learning Technologies Unit of Aetna, Inc.
About the Author: Stan Malcolm serves as a coach to companies wishing to develop or review their strategies for performance support, learning technologies, and/or corporate learning issues generally. Formerly, he headed learning technologies and performance support initiatives at Aetna, Inc. He can be reached at Stan@Performance-Vision.com or 860-295-9711.
