RESEARCH ISSUES IN ADVANCED OFFICE INFORMATION SYSTEMS
Chandra S. Amaravadi
Department of Information Management and Decision Sciences
College of Business and Technology
Stipes Hall 435
Western Illinois University
Macomb, IL 61455
Ph:309-298-2034
Email:
Working Paper
Submitted to Data Base
April 2004
RESEARCH ISSUES IN ADVANCED OFFICE INFORMATION SYSTEMS
Abstract -- The slow growth of productivity in the service sector may be explained by one fundamental limitation of current office technologies; the inability to provide functional support to office workers. Functional support is the ability of office systems to support adhoc task and information requests such as updating a project schedule or filing an expense report. This will be an ideal for fifth generation systems (FGOIS) and will require progress on a number of fronts including an improved understanding of forms structures, document operations, integration of application models with process models, documentation and formalization of tool activity and finally in techniques for managing large scale operational knowledge. In addition since our understanding of office activity is extremely limited, the paper calls for empirical studies of organizational processes as well as operational knowledge.
Index Terms: FGOIS, Advanced Information Systems, Research Issues in Advanced Information Systems, Fifth generation information systems, Office Information Systems, Process models, Knowledge Management.
INTRODUCTION
Despite decades of investment in information technologies, there have been no appreciable gains in productivity in the service sector. Between 1985 and 2000, the index of productivity in the service sector increased at an average of 1.8% per year, while during the same period, index of productivity in the manufacturing sector increased at an average of 3.7% per year (Jacobs 2001). While part of the problem may depend on the way productivity is measured (output per person) (Quinn et a., 1994), the real problem may lie in the awkwardness and imprecision of today’s information handling activity. For instance, consider the job of a training co-ordinator (TC) at a software consulting company we will call BSS[i]. The TC identifies training needs from the company’s project managers (PM) and develops a monthly schedule of training sessions. He/she then identifies “faculty”[ii] to conduct these sessions. The training schedule is placed on the web and interested persons fill a small form online. The TC collects the information from the web and prepares a list of “trainees.” He/she compiles a mailing list and sends a reminder to all trainees, a few days before the start of the session. When the session starts, the TC takes attendance and feedback (if any) and submits them to the Human Resources department. Faculty evaluations are also collected and submitted to management. Although this is seemingly mundane activity, the TC carries them out manually, via a “software bureaucracy,” i.e. through an endless number of “point,” “click,” “type,” “copy” and “paste” operations. The system does not automatically send email to the PMs or compile a trainee list or automatically send reminders. This is a classic scenario that is repeated in countless organizations world wide for reasons that are well known (Amaravadi et. al, 1995): a) Companies lack the resources to develop a custom solution. Besides, customized in-house applications (as well as "off-the-shelf") lack connectivity to desktop software such as word processing and database, b) There are a number of other important targets before companies can implement workflow solutions to the assorted activities which make up administrative work., c) No single software would satisfy all the automation needs without imposing its own version of a “work pattern,” d) If a software package were available, it would either be difficult to customize or lack the customization features. For instance, the author was approached by a company that wanted to store email addresses in a database and to send mail messages based on these addresses. This proved infeasible because the email package which was used in the company could not be customized to read database files.
Thus, desktop software cannot completely fulfill the needs of office tasks and customization is limited by the features or hooks provided in the package. It represents a sunk investment since it cannot be easily transferred to another workstation or re-used especially if there are minor differences in the environment.
These limitations can be attributed to office systems having limited capabilities for functional support. This is the ability to specify an adhoc sequence of tasks in a dynamic, application-independent, friendly, transparent and non-obstrusive fashion. The lack of functional support may explain the slow increase in productivity in the service sector in the face of capital investments. On the surface this seems a technological problem, but in reality, the problem is intertwined with the nature of office activity and its formalization. This paper attempts to identify such issues, by evaluating the progress of desktop technology and linking problems therein to research needed in the area.
THE NATURE OF THE TECHNOLOGY
Office systems have evolved in a number of generations starting with stand-alone PC applications and moving through integrated applications, groupware and workflow in the second, third and fourth generations respectively (Amaravadi et al., 1995). The capabilities and features of the fifth generation systems (FGOIS) are still in the research stage. The common vision shared by many researchers is a system which can act as an assistant and carry out tasks on behalf of the office worker (Amaravadi et al. , 1992; Ellis and Naffah 1987; Faidt and Karagiannis 1990). Such a system will have the following capabilities:
§ It will accept limited types of natural language inputs
§ It will be accessible from any location.
§ It will be accessible from any application
§ It can provide knowledge support
§ It can support process requests as well as adhoc task requests
§ It can support the user in problem solving
FGOIS will be able to understand limited natural language requests and carry out tasks on behalf of
the user. They will also provide information and limited support for problem solving. The widespread usage of the internet will mean that they will be accessible from any location. This capability will in fact act as a sort of “Turing” test for an ideal office system. If the office worker is able to completely carry out all office activity that is not inherently manual (such as inspecting a sample) from a remote location, then the OIS would pass the automata test. To achieve this ideal requires addressing a host of challenges, including incorporating Artificial Intelligence technologies, studying the nature of office work, developing more detailed office models, as well as rethinking office architectures. However, the limitations in achieving understanding and problem solving behavior in machines will imply that we will be able to meet the “Turing” ideal for administrative work rather than for professional and managerial type of work. This in itself is a significant goal as it would have a dramatic impact on productivity. Unfortunately current technologies lack this thrust.
Traditionally, office applications have evolved from being stand alone applications (such as Wordstar) aimed at clerical support to being integrated and shared across networks. In its current form, the desktop is dominated by monolithic applications accessible from a common operating environment (see Figure 1). While the number of features within an application are prodigious, user-system and application-application communication features are extremely limited. Users can carry out dynamic data sharing by copying and pasting information on a “clipboard,” that can be shared by other applications. In addition, files can be linked on a limited basis. Data such as a budget file can be linked to a document such as an annual report so that changes in the budget file are reflected in the report. While the implementation of such links is problematic (they lack global visibility ), the greater problem is the limited access to application features, from outside the application.
For instance, it is not possible to ask the system to remember a phone number when one is within a mail program or update a project deadline, without actually getting into the software. Such command level invocations would lead to users being able to inter-weave their tasks with system commands, leading to functional support and it is hoped, substantial improvements in productivity.
Since the capabilities discussed above are not part of current OIS systems, it is necessary to re-architect office systems to incorporate these capabilities. One possible approach has been illustrated in figure 2. In this scenario, the Operating Intelligence (OI) replaces the operating environment as the launching point for the user’s applications. Through the OI, users will launch their browsers, spreadsheets, word processing as well as web applications. The OI will be accessible from within any application as well. It will allow users to request, in a structured natural language, any actions that the system should take on their behalf such as for e.g. sending a meeting reminder to participants in a list. This will essentially reduce to a command-line type interface to all applications in this context. In distributed settings, office workers will be able to invoke the OI and carry out actions from remote/mobile locations. The architecture includes access to conventional applications as well as the newer applications such as groupware, workflow and web applications. The OI will be the launching point for initiating applications as well as workflows such as making reservations or claiming business expenses. An “operational knowledge“ component provides the interface to all operational knowledge, regardless of whether it is required by the user or by an application. Also included at the server level are application objects (“component objects”) corresponding to application commands which the user can freely invoke from the OI. Alternatively, these can be freely invoked by other applications as well. Thus the user is able to request information such as the building code in a particular municipality or request a process such as “filing a building permit” from the OI and the request will be executed from the server components. Such an architecture is no doubt ideal, but its development is contingent on an understanding of office work rather than technical issues alone.
THE NATURE OF OFFICE ACTIVITY
There have been a number of studies of offices, both qualitative as well as quantitative. The quantitative studies attempted to identify the proportions of time office workers spent on various activities such as typing, filling forms, reporting etc. (Christie 1985; Engel et al. 1979; McLeod and Jones 1987; Morgenbrod and Schwaertzel 1980; Poppel 1982; Tchachenkary and Conrath 1982). The qualitative studies reported on problem solving processes in organizations (Gerson and Star 1986; Suchman 1983).
A majority of the studies date back to the seventies and eighties. The usefulness of the studies is limited by their purpose as well as the underlying paradigms used to collect the data. The early studies were intended to identify the scope for office information systems and were therefore focused on the activity paradigm. This meant identifying the proportion of time spent in each activity. Even within this paradigm, there was a tremendous variation in the terminology, owing obviously to the infancy of the field. For instance, one study classified office activity into “advising,” “deciding,” “approving,” “arranging,” “scheduling,” etc. while another classified it into “writing,” “proof reading,” “calculating,” “mail handling,” etc. The percentages of time spent in each activity are themselves not very useful and this is compounded by the differences in terminologies so that attempts at aggregating the data across studies are defeated.
The qualitative studies focussed on the co-operative nature of office life required especially to interpret policies and to resolve problems (Gerson and Star 1986; Suchman 1983). Gerson and Star (1986) reported on the due process (“articulation”) that accompanies the pricing and classification of medical services while Suchman (1983) reported on the due process that accompanies the troubleshooting of purchase orders in an accounting office. Both these studies highlight the richness that seems to characterize office work. Classification of medical procedures or troubleshooting of purchase orders requires “articulation,” the set of activities that are required to perform a task. These include discussion, negotiation and information exchanges with various entities within and beyond the organization.
The relevance of the studies (both qualitative and quantitative) is questionable because of the drastic changes in business in the last two decades. The types of employees, their relative proportions, their activities and the technological infrastructures have undergone radical if not catastropic change. The shift from clerical to knowledge work and group work; the technological shift into an integrated operating environment and to the internet are well known examples of these changes. Not surprisingly recent studies have tended to focus on knowledge workers and knowledge work processes (Davenport, Jarvenpaa and Beers 1996; Perlow 1999; Rouncefield et al., 1994; Shultze 2000). The last three studies are ethnographic studies focussing on software engineers, administrative employees and software engineers respectively. Davenport et al.’s (1996) study focused on knowledge improvement processes in a sample of thirty organizations. These processes revolved around finding existing knowledge, creating, applying, packaging and reusing it. The knowledge process re-engineering efforts ranged along a continuum of laissez-faire (knowledge workers given control of the process) to radical (where activities in a process were re-structured by a design team) with most tending towards a middle ground or a participative approach. The Perlow (1999) and Rouncefield et al. (1994) are sociological studies which among other things highlight also the co-operative and interdependent nature of office work. Perlow’s ethnographic study in particular focused on the usage of time by a team of 17 software professionals and its impact on their work. The study found that although 30% of an engineer’s time was spent in interacting with others, these interactions were disruptive to the 60% of time that they were spending, working alone on the “real engineering.”
The major criticism of the studies is that they had a thesis other than the automation of office work (from a technical standpoint) owing apparently to the different paradigms which they represented. For instance, the emphasis of Davenport et. al’s study was to identify effective re-engineering approaches for knowledge work processes. The emphasis in the Rouncefield et. al study and the Perlow study was to focus on interruptions in office work. There has been a general failure in the literature to focus on models of office work from the perpective of automating the office, leaving little theoretical ground on which future studies could be based. Towards this end, a possible framework describing office activity (for all types of office workers) is presented in figure 3. A number of studies indicate that office workers spend a significant amount of time on non-work related activities (Perlow 1999; Poppel 1982; Rouncefield et al. 1994) suggesting that office work could be broadly classified as functional and non-functional. Functional work is the activity related to work such as preparing budgets, searching for information etc. while non-functional work is activity unrelated to work such as waiting for appointments or conversing with other employees on non-work issues. Poppel’s study dating back to 1982 suggests that as much as 19% of an employee’s time is taken up in non-functional activity. The percentages of time spent in each type of activity is essential to building a framework of office work.