RESEARCH ISSUES IN ADVANCED OFFICE INFORMATION SYSTEMS

Chandra S. AmaravadiDepartment of Information Management and Decision Sciences

College of Business and TechnologyStipes Hall 435

Western Illinois UniversityMacomb, IL 61455Ph:309-298-2034

Email: c-amaravadi@wiu.edu

Working Paper

Submitted to Data BaseApril 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 BSSi. 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,

1

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.

2

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.

3

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.

4

Figure 1. Contemporary OIS Architecture

WordProcessing

Operating Environment

Spread-sheets

WebApplications

Database

HardDisk

Data exchange

Data exchange

Manual data support

Manual data support

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.

5

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 6

Figure 2. FGOIS Architecture

WorkflowApplications

OperatingIntelligence Desktop

Applications

WebApplications

OperationalKnowledge

Component Objects

Application support

Knowledge support

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,

7

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.

8

The sub-classification of functional activity into process (“formalizeable”) and non-process (“non

formalizeable”) work has been pioneered in the Morgenbrod and Schwaertzel (1980) study and has been

widely accepted in the OIS literature. We will regard a process as any non-manufacturing organizational

activity such as hiring employees, approving proposals etc. which consist of a series of steps executed

together. Work that consists of only one step would be classified as non-process work. Morgenbrod and

Schwaertzel’s study suggests a breakdown of 25-43% for process work and 57-75% for non-process work.

The manner in which these percentages vary with the types of offices as well as the type of office worker is

also of theoretical interest. One would expect administrative employees to be more involved in process

related activity than knowledge workers (Davenport et al. 1996). Process work is further divided into

“prescribed” and “ad-hoc” following popular classifications (The 1994). Prescribed processes are those

that are formalized and often written in procedure manuals, while ad-hoc processes are one-time processes

that are spontaneously carried out, such as deciding to confer an award or dealing with a crisis.

Additionally, processes can also be classified into managerial, administrative and knowledge-intensive

processes (these are not shown on the diagram), following Garvin’s classification (Garvin 1997). Owing

to the tremendous commercial significance of process improvements, empirical studies involving

characterization of different types of processes, identifying their frequencies of occurrence and comparisons

among them are required.

While supporting processes with information technologies present some technical and conceptual

challenges which we discuss subsequently, the greatest challenges will stem from attempting to support

non-process work since it is more difficult to model. There is not much quantitative data about this type

of work. The activity studies mentioned earlier attempted to simply identify the amount of time spent in

activities such as filling forms, advising etc. without regard to whether they were carried out as part of a

process or not. We will assume that non-process activity could also be roughly classified into those

9

which involve communication and those which involve information handling (Morgenbrod and

Schwaertzel 1980) (Please refer to figure 3). Communication activities include meetings, phone calls,

sales calls etc. We have grouped this into the category of communication and discussion. The

information handling activities could be further classified into information search and receipt,

assimilation and analysis, and packaging/dissemination, as supported by the Davenport et al. study. Thus

non-process activity is classified as follows:

information search and receipt, information assimilation and analysis, information packaging and dissemination, Communication and discussion.

10

OFFICE ACTIVITYOFFICE ACTIVITY

NonNon--functionalfunctionalFunctionalFunctional

ProcessProcess NonNon--process process

PrescribedPrescribed

Info. Search & receiptInfo. Search & receipt

Information packagingInformation packaging

Communication & discussionCommunication & discussion

Assimilation & analysisAssimilation & analysis

AdAd--hochoc

Figure 3. Classification of Office Activity

The classification subsumes activities such as filling forms, typing memos, deciding, approving,

arranging, scheduling etc. which were originally identified under the activity paradigm. Empirical work

can establish the validity of the classification and identify the different percentages of time that are spent

in each. It is also necessary to have qualitative evidence concerning the nature of non-process work so

that further models could be developed. The classification will provide the necessary theoretical

foundation for further improving our understanding of office work. It will also serve as a generalized

model for measuring the impacts of OIS. For instance, with the implementation of generic OIS

technologies we should see a shift towards functional work (and away from non-functional work)

Similarly, with the implementation of workflow systems we should notice a shift away from process

work, towards non-process work. As necessary as the classification is to a theory of OIS, it does not

contribute towards the understanding of functional support as described in the introduction. For this, we

need to turn our attention to office models, a topic that is discussed next.

MODELS OF THE OFFICE The majority of the OIS literature is concerned with office models, reflecting their important role in

automating office systems. The traditional modeling literature dates back to the eighties; contemporary

literature has tended to focus on workflow (process models) but some of the issues identified are similar

as we point out. Inspite of the tremendous diffusion of research in this area there appears to be some

degree of agreement about the different areas of modeling (Amaravadi et al. 1995; Conrath & Ang 1987;

Desai 1991). These include: forms, knowledge, procedures, functions, agents, communications,

problem solving and applications. The interdependencies among these areas are illustrated in Figure 4.

The basic premise is that office activity is executed by agents (human) to fulfill an organizational

purpose or function. This could be performed in the context of a procedure (process) or it could be

executed on an adhoc basis (non-process). The type of activity could be filling forms/ obtaining

information, sending communications, making decisions or problem-solving (Amaravadi et al. 1992; 11

Figure 4. The Different Areas of Modelling and their Relationships.

FUNCTIONS/GOALS

Achieved by

PROCESS ACTIVITY

NON- PROCESS ACTIVITY

decisions, problems, communications

Can consist of Can consist of

forms/documents

Uses Uses

agents

Carried out by Carried out by

Carried out by

Tools/applicationsCarried out by

Hasrules/conditions

Needsofficeknowledge

Riddle 1996). Activities carried out in the context of a process are governed to a greater extent by rules

and conditions than non-process work, which relies more on random items of knowledge. For instance,

processing of grant applications are governed by official deadlines and formal criteria whereas an

individual employee can buy a parking sticker or make travel arrangements governed by his/her own

constraints. It is hypothesized that operational knowledge (or office knowledge) will be helpful as

employees carry out such adhoc activity. Regardless of whether the work is process-related or not, the

activity is executed on a tool or an application such as email, word processing etc. The results of an

activity could fulfill a purpose or stimulate further activity, continuing the cycle until the process is

completed.

12

Research on models was initially focussed on forms, data models and procedures and extended

into communications, agents, problem solving, applications and knowledge management. Providing a

detailed critique of the modeling literature is beyond the scope of this paper and has been presented

elsewhere (Amaravadi et al. 1995). Instead, the main issues in the different areas will be identified.

Models in all areas have been developed to varying degrees but the research is far from complete.

Forms Perspective

In the forms perspective, database models of forms and specifications of form operations have

been developed (Bernal 1982; Lum,Choy and Shu 1982; Tsichritzis 1982; Yao et al., 1984). Forms

models are generally adaptations of basic hierarchical or relational data structures which consist of groups

of attributes that are mapped to base tables. The external presentations of forms correspond to database

views and include fields and labels as well as other information such as instructions, page numbers etc.

Form operations include form filling, filing, update, copying, retrieval and transmission. The interface

aspects of these operations and integrity problems that can arise have been addressed. The representation

of forms is still an area needing research. The conventional approach of storing form data using

normalized base tables is very awkward because of the interdependence among attributes and the need to

model operations on such attributes (derived attributes) which require simultaneous visibility of other

form attributes. In tax forms for instance, the tax rate will be based on filing status and gross wages

which are filled earlier in the form. Frequently, attributes of a form such as capital gains in a tax form are

looked up from other forms or tables. To build intelligence into forms applications therefore requires a

conceptual representation that is closer to its actual presentation than one having data partitioned into a

number of normalized tables. A conceptual level view (McFadden & Hoffer 1999) having all the form’s

data types such as date-ranges, income classification, data aggregates etc. is more appropriate for

advanced forms applications (see WFMC 1998: p54 for generic types). Such data types will suitably be

identified from a thorough research into forms structures and data filling operations. A systematic study

13

and documentation of the logic of form operations is also warranted.

Documents Perspective

A number of data and document models have been introduced into the OIS literature which have

been inspired by semantic data models (Harper, Dunnion , Sherwood-Smith, & Van Rijsbergen 1986;

Lamersdorf, Mueller and Schmidt 1986; Loucopoulos et al., 1991; Pernici et al., 1991; Wang and Ng

1992). These models address three main aspects of data modelling: classification, object

definition/relationships and activities. As in object oriented models, data objects have been classified

into types -- structured objects such as forms, memos, financial worksheets etc and unstructured objects

which have free form text and graphics. Some models such as Minstrel-ODM (Harper et al. 1986) and

TEMPORA (Loucopoulos et al. 1991) allow for non-exclusivity in the classifications, resulting in a

network structure of object types (rather than a hierarchy). The definitions of object types make use of

such well known mechanisms as abstraction, reference, object composition, object instances, derivation,

time-stamping etc. In TEMPORA for instance, objects can be simple, composite or derived. Composite

objects are those which consist of other objects; for instance, a document could consist of “author,”

“abstract,” “table” etc. each of which are individual objects. The details of composite objects are not

shown in the main schema but in the object’s sub-schema. Derived objects are specified by constraining

simple or complex objects with conditions. For instance, a proposal can be viewed as a document that is

‘submitted for evaluation.’ Objects can have a variety of relationships with other objects such as “part-

of,” dependent, independent, exclusive etc. Dependent objects for instance, are objects whose existence

depends on other objects. Thus a “car engine” is a dependent object of “car.” The activities performed

with objects usually include storage, presentation, retrieval, deletion and update (Ang and Conrath 1993).

There has been a tendency in the research to define these activities in terms of their relational equivalents

which causes problems similar to those in forms viz. the inability to define higher level activities. The

representation must be close to the native form of the objects or operations on them become awkward. A

14

second major criticism is that the implementation perspective has been missing from many of these

approaches. This is perhaps due to the fact that maintaining the various types of objects and their

relationships while ensuring the fulfillment of integrity constraints is an extremely complex problem.

Additionally, many of the operations, such as querying will depend on the object type. In recent years

there has been a push towards representing digital documents using mark up languages. The markup

languages are domain dependent and have been developed for certain domains such as bibliographic

databases (Ram et al., 1999). But generalized semantic models fulfilling a variety of data needs in

practical office situations continues to be a research challenge. Models of document operations which go

beyond simple retrieval such as, extracting parts from different documents are also of interest to the

FGOIS endeavor.

Process Perspective

The process perspective is one in which contemporary research dovetails with traditional work.

Processes have been modeled using both graphical and declarative techniques. Graphical specifications

are usually variations on Petri-Nets, Data flow diagrams, State transition networks or activity networks

(Amaravadi et al. 1992; Ang and Hong 1994; Barbic et al., 1985; Ellis and Nutt 1980, Kreifelts and

Woetzel 1986) while declarative techniques specify processes using programming languages (De Jong

1987; Kreifelts and Woetzel 1986; Pernici et al., 1991). A similar pattern is found in recent work where

researchers have used Petri-nets, variations on state transition networks, program specification

techniques, and additionally transaction models, UML, logic and frames (Alonso et al., 1996; Alst 1996;

Basu and Blanning 1999; Grundy et al., 1998; Koubarakis and Plexousakis 2002; Ngu et al., 1996 ).

The criticisms of these approaches are best described by the concepts of domain adequacy and

representational adequacy (Amaravadi et al. 1995). Domain adequacy refers to the extent to which the

models incorporate all elements of a process while representational adequacy refers to the extent to

which the model incorporates the control structures necessary to specify the process. Fortunately, both

15

have been defined by the Workflow Management Coalition (WFMC 1998). The domain dimension

includes “activities, “ “participants” (i.e. agents), “transitions” (i.e. pre- and post conditions),

“workflow relevant data” (data needed by the application as well as decision data) and “application

assignment” (i.e. a module which executes the activity). The representational dimension includes basic

control constructs such as “in-line block,” “loop,” “split,” and “join.” For full details, readers are

referred to WFMC (1998). There is an additional dimension to representational adequacy, a concept best

described by the three-schema architecture (TSA) in databases (McFadden and Hoffer 1999; Preuner and

Schrefl 2000). External models are viewsiii of processes, conceptual models are those where there is a 1:1

correspondence between the model and the domain, while internal models are implementation level

models and often manifest in the form of software specifications. The perspective that models need to

have different levels of abstractions has often been missing in the literature. Evaluating models along the

TSA and identifying effective practices is clearly a pressing research task. Additional process issues are

discussed subsequently.

Problem solving Perspective

The realization that business processes are not as straightforward as they seem (Gerson and Star

1986) led to a number of attempts at dealing with problems and exceptions. These are hypothesized to

occur as a result of missing information, missing employees etc. Also known as adaptive workflow,

problem solving approaches have attempted to rely on artificial intelligence techniques such as

consistency checking, hierarchical planning and alternative goal/agent specification (Ang and Hong 1994;

Dellen et al., 1997; Karbe et al., 1990; Kreifelts and Woetzel 1986, Chung et al., 2003). This is an agenda

that is subjected to the well-known challenges in AI such as problem-specificity, goal specification,

dynamic specification of goals, representing the different problem states and specifying the conditions

under which alternative goals may be sought. Understanding the process of problem solving as it is

carried out in offices is a more achievable research goal requiring both quantitative and qualitative

16

evidence on the nature, extent and types of problem solving.

Agent Perspective

Procedures are executed by human agents within the context of the goals and policies of the

organization. Agent’s roles and responsibilities have been modeled using sets, predicates and objects

(Aiello et al., 1984; De Jong 1987; Pernici 1990). An interesting approach is to model the different

roles of an agent (such as “manager,” “team member,” “sub-ordinate”) with a set of properties describing

the agent, the states which the agent could have (such as “assigned,” “re-assigned,” “suspended,”

“terminated”), the set of messages that the agent could receive that would move the agent to the different

states (for e.g. “assign, “ “on leave”) and the rules for transitioning among the states (“if leave is approved

suspend-role(project manager)”) (Pernici 1990). Goals and policies have been modeled with the Actor

Language (similar to LISP) , with rules, and with logic (De Jong 1987; Lee 1988; Loucopoulos and

Katsouli 1992). As with the problem solving perspective, there is a similar limitation of a lack of

empirical evidence regarding the types of policies. Modelling of policies does not appear to present any

special problems given the variety of languages available today, however, the manner in which they

influence processes is still of research interest. For instance, how do organizational policies influence the

hiring of a contractor? Are policies implemented implicitly by the agents or explicitly? At what stage in

the process are they an issue? Implementation research could take the approach of identifying and

developing policy objects accepting a given situation as input and assessing whether or not a policy is

violated. Can a part time employee work for more than 10 hours of overtime in a given week? Agents

communicate with other agents and with applications, but research in these areas has been comparatively

sparse.

Communications Perspective

In communications, two approaches are distinguishable, one to model the different types of

17

messages and the actions taken on them, corresponding to the policies of the organization (Malone et al.,

1987) and the second is to model a procedure in terms of a canonical set of message exchanges (Auramaki

et al., 1988). For a discussion of the former type of work, please refer to Motiwalla and Aiken (1993). It

is in the latter area that there is a lacunae in the research. Qualitative evidence regarding the pattern of

communications in various office contexts would contribute to the agenda of integrated task support. For

instance, it is desirable to be able to predict the possible types of messages that would be exchanged in

purchasing materials from a vendor since these would provide a context for an intelligent system to

understand a user’s request. Recent work has focused on the interdependencies that occur in co-operative

work processes (Clancey et al. 1998, Grainger et al. 1998). These can be visualized as extensions to the

WFMC activity model where work is executed by a group of agents (rather than by an individual) having

its own set of rules and constraints.

Application perspective

Traditionally, the application perspective has focused on task-tool interdependence but our

understanding in this area is limited to the idea that tools such as email and databases can be invoked to

support communication and retrieval tasks (Amaravadi et al. 1992; Ang and Conrath 1993). For

achieving advanced systems, it is essential to analyze the type of functions (such as adding a paragraph to

a document) that can be invoked from outside an application and the knowledge needed to carry out these

operations i.e. the application services (Yang 2003). The provision of such services is dependent on

application usage, the sequence of tool-operations that a user carries out. For instance, “what are some

typical tool-operation scripts for an accountant? for a training co-ordinator? project manager?” The

study of usage of different tools in different contexts therefore presents a research opportunity.

Additionally, services depend on other services. Sending mail for example, might involve compiling a

participant list first. Both type of services and type of usage need to be documented for FGOIS. In

recent years there has been an interest in evolutionary or adaptive systems (Lycett and Paul 1999;

18

Sutherland and Heuval 2002). The underlying issues are too extensive and perhaps merit a separate

paper, but for OIS researchers, the main interest is in further articulating the concept of an “evolutionary

office system. “ What should such a system learn and what should it ignore?

Discussion

In general, and as pointed out earlier, empirical understanding of the nature of office work is

extremely limited, but crucial to the further development of OIS. When such understanding is limited,

researchers are forced to make assumptions in their models. For instance, in forms approaches, the types

of data structures that can potentially occur is a major assumption. In the process perspective, some of

the declarative approaches have included the assumption that inputs to a process will be in the form of

attribute-level data which can be described by parameters. Whether or not such assumptions are justified

needs investigation. The lack of empirical knowledge hinders our ability to evaluate models. For

instance, researchers cannot know for certain whether a particular model has the constructs necessary to

model all process situations. Benchmark cases will certainly assist in this effort.

A second major limitation of the modeling literature is that research in individual domains has

tended to be standalone and self-contained. The view that the domains have to provide certain services to

an integrated system is largely missing from the research. Examples of such services include: in the

forms perspective, being able to fill forms from multiple data sources; in the data perspective, to extract a

data sub-object from a complex object and to perform manipulations on it; in the agents perspective, the

ability to re-assign work to agents, the ability to change roles dynamically, the ability to search for agents

with certain skills etc.; in policies, accepting decision situations and assessing whether or not the situation

conforms to policies; in communications, being able to identify the set of message templates appropriate i Based on personal observation while a consultant with BSS. The name is disguised.ii Faculty could be external or internal, such as a senior programmer.iii Process views correspond to the notion of database views i.e. they are the representations of processes from the user’s perspective.

19

in a communication situation. In a project situation these would include requesting project meetings and

project status; the set of services in the application perspective are likely to be the greatest in number, but

least researched. Examples of these range from the mundane to the more complex – “send project

management presentation to Mike,” “Add Leff to participant list for web workshop,” “Register for

upcoming ACM conference and make hotel reservations.” Identifying and documenting such usage is the

responsibility of researchers and is essential to OIS research.

To this stage, we presented research issues primarily from the point of view of the traditional

literature, viz. the different areas of modeling. It is important to view research areas from the point of

view of the domain to be automated viz. organizational activity. Thus analyzing issues from the

perspective of office activity ( “process” vs “non-process”) work is more fruitful so we present a

discussion along these lines.

PROCESS ISSUES

Process research or more popularly known as workflow research presents a bewildering number of issues.

These can be conveniently categorized into specification tools, models (see previous section on process

models), process portfolios, architectures and execution issues. Specification tools are generally graphics

based and support the definition of the workflow schema. The graphical representation of specifications

would form the external level of the three schema architecture (TSA). The main criterion here is

flexibility in being able to specify a wide range of processes using the tools (see Grundy et al., 1998).

Generating different views of the same process (Agostini and Michelis 2000, Liu and Shen 2003)and

providing knowledge support during process execution, especially in knowledge intensive processes are

interesting new directions (Abecker et al. 2000, Corkill et al. 2003). At the present time, information

support services are being embedded in the process definition, but in future, such support is more

appropriately provided from an OKSS server (see next section) for greater flexibility. Specification of 20

co-operative processes is subject to group constraints as previously discussed (see Clancey et al. 1998,

Bogusch et al. 2001). Conceptual models or logical models can be classified into those which use:

variations of Petri/activity network or state transition diagrams (Lee 2002, Basu and Blanning 1999),

database transaction models (Grefen 2002), and programming language specifications, most notably

logic (Lee 2002, Koubarakis and Plexousakis 2002). As pointed out earlier, the issues in these have been

well understood and the needed constructs have been standardized by the WFMC. The extent to which

the different models have achieved domain and representational adequacy is of interest. Further

improvement in models requires research into processes: the differences between different types of

processes, the types of triggers normally used in processes, the average time of completion, and the type

and frequency of problems/exceptions. In the area of architecture, the set of process services to be

provided by a workflow engine have been specified (WFMC 1998). These include initiating, suspending,

obtaining the status etc. of processes. Application objects which execute steps in the process are specified

in the process definition. Architectural integration of such objects (they form the lowest level of the

three-schema architecture) with desktop and web applications remains a technical challenge (Preuner and

Schrefl 2000; Yang 2003). There is room for common standards to be developed.

The collection of processes in an office and their interrelationships are referred to as the process

portfolio (Amaravadi 1999). The main issues that are presented here are modeling, detecting and

enforcing interdependencies among tasks. Interdependencies may involve simultaneous execution or

enforcing of precedences. In the customs area for example, interdependency manifests as precedence in

the preparation of shipping documents. A company needs an export clearance before it can prepare a

shipping document. Various types of rules and logics have been developed to model interdependencies

(Attie et al. 1996, Casati and Discenza 2001), but the control of execution and its physical representation

are ongoing issues. Online documentation of process portfolio would be useful from the user’s standpoint

(Amaravadi 1999). Other issues that arise during execution of processes includes algorithms for adaptive

21

workflow, optimization, deadlock detection, and recovery all of which are problems with no

straightforward resolution (Chung et al. 2002, Sadiq and Orlowska 2000). Thus process models involve

the complete range of problems from process specification to process execution.

NON-PROCESS ISSUES

The office studies discussed earlier seem to suggest that the most effective function served by an OIS for

non-process work is supporting information handling of office workers. The storage and retrieval of

structured information, documents and images can be effectively addressed with conventional database,

information retrieval and imaging technologies respectively. What presents the greatest challenge for

researchers here is perhaps the management of organizational knowledge/information. Systems

managing such knowledge are related to Knowledge management (KM) systems but emphasize

operational knowledge rather than strategic or professional knowledge. For lack of a better term, we will

use OKSS (operational knowledge support systems) to refer to such systems.

There seem to be three main technical approaches to OKSS – the document, knowledge

engineering and the ontological approaches. Knowledge can be viewed to be in the form of documents

containing important information in the first case (Mann et al. 1997, Zack 1999) or in the form of

knowledge structures in the second case (Rosner et al. 1998, Amaravadi 2001) or in the form of

semantically organized information in the third case (Abecker et al. 2000, Ontoprise 2003). Within the

document perspective, a number of approaches suggest the meta-organization of documents, usually into

topics and subtopics (Hackbarth and Grover 1999; Retallick and Sanchez 1998; Vail 1999). The latter

two approaches are obviously of more interest since the system will have to ultimately serve the purpose

of answering questions – a feature not possible in the document perspective. Work on codifying

operational knowledge has begun to emerge. Both conventional representation schemes (Abecker et al.

22

2000, Amaravadi 2001) as well as special purpose schemes such as RST (Mann and Thompson 1988) are

being employed. In the TechDoc project, researchers identified the natural structure of maintenance

manuals (e.g. description, location of repair object, replacement parts, pre-conditions etc.) and used the

RSTiv scheme to represent maintenance operations (Rosner et al. 1998). The challenges here are the

same as in AI, finding domain independent methods of organizing, partitioning or classifying (in the case

of ontological methods) the knowledge items as well as automated acquisition. Since the number of items

of operational knowledge is likely to be in the thousands, large scale architectures that do not degrade

with volume are of special interest. The nature and characteristics of operational knowledge are however

unknown. Based on informal studies, this has been characterized as mundane, concept and relationship

oriented but empirical study is required to validate these characteristics.

Additionally, a number of philosophical and practical issues need to be addressed in order to

manage administrative knowledge. The philosophical issues lie in defining the objectives of the OKSS

for e.g. should the functions be designed for current technologies or future technologies? Will it serve as

a static repository, or will it serve as an active knowledge base? Would it be aware for e.g. if incorrect

knowledge is entered? How can knowledge be verified? There are practical issues to be dealt with such

as the appropriate mix of technologies to be used and identifying the initial set of knowledge for the

system. OKSS also present some interesting organizational issues, for e.g. implementing mechanisms for

maintaining the knowledge, ensuring its consistency, rewarding knowledge contribution, ensuring privacy

while still tracing contributions etc.

CONCLUSIONS

Judging by the potential for productivity improvements, research in Office Information Systems is far from

complete as popularly thought. The main stumbling block is a lack of flexibility and grace in specifying

iv RST uses semantic relations such as temporality, causality, motivation-action etc.23

adhoc tasks to the system i.e. current systems lack the capability for functional support. As discussed in the

paper, achieving functional support requires re-architecting current systems such that they include

command-level natural-language interface to all application features. Referred to as FGOIS systems, the

next generation systems will need to understand user’s requests within limited contexts and carry out the

tasks as requested by them. Such systems will also provide primitive knowledge management capabilities

for operational knowledge. FGOIS capabilities require an understanding of both the nature of office work

as well as the manner in which it is formalized i.e. described by models. A framework of office activity has

been proposed, based on the limited quantitative and qualitative studies that have been carried out.

Validating the framework will be the first step towards a theory of office work. Office work is mainly

classified into process vs non-process work. Our understanding of both types of work is extremely limited.

For instance, we do not have empirical data on the types, similarities and differences between the different

types of processes, their durations and triggers. Similarly, we do not have a complete understanding of

what constitutes non-process work. Both are critical to the further development of advanced systems.

The second aspect of functional support is the formalization of office work, which includes both

process and non-process work. There have been several process models, based on variations of graphs,

Petri-nets, DFDs, software specifications etc. The basic idea of processes as aggregations of activities with

pre-conditions, post-conditions, inputs and outputs is present in most of the schemes. However there seems

to be a failure to distinguish between the external, conceptual and internal levels of the model; resulting in

evaluation problems. More important are the underlying assumptions of models which need empirical

verification. For instance, can all process conditions be described by rules? Can all process inputs be

described at the attribute level? Process models involve also modeling of various sub-domains, which

appear as different areas of the OIS literature – forms, documents, agents, functions etc. These subdomains

provide various services to the system, which also need to be scientifically documented. For instance, what

are the set of services to be provided by the agents sub-domain? Communications sub-domain? Ultimately,

24

we will need mini-process models of the sort, “make travel reservations” and a universal definition of all

application objects required to achieve such actions. There are also integration issues which occur at the

internal/architectural level of TSA, how should application services be integrated with desktop

technologies? What sort of standards are appropriate here?

Non-process work also represents a significant but largely untapped area. Our hypothesis is that

among other activities, it includes information search and receipt, requiring the extension of office systems.

OKSS will be based on semantic models of operational knowledge, which is also an area needing empirical

study. Starting out with the concept of functional support, we have identified a host of research issues,

from technologies, to empirical studies and models. In the babble of new technologies, FGOIS issues risk

being diffused into Knowledge Management and Workflow, each of which have emerged as independent

domains in recent years. But process support and non-process support ought not to be distinguished as they

share much in common especially at the architectural level. Enhancing office productivity is so important

and the method of achieving it so fundamental to information systems, that these issues cannot be neglected.

REFERENCES

Aalst, V. D. W.M.P. (1996). Petri-net-based Workflow Management Software. Report from the NSF Workshop on Workflow and process automation in information systems. Siggroup Bulletin, April, 18(1).

Abecker A., Bernardi A., Hinkelmann K., Kuhn O., Sintek M. (2000). Context-Aware, Proactive Delivery of Task-Specific Information: The KnowMore Project, Information Systems Frontiers, October, 2(3-4), 253-276.

Aiello, L., Nardi, D., and Panti, M. (1984). Modeling the office structure: A first step towards the office expert system. ACM SIGOA Conference, 25-32.

Alonso, G., Agrawal, D., Abbadi, A. El., Kamath, M., Guenthoer, R., Mohan, C. (1996). Advanced Transaction Models in Workflow Contexts in Proceedings of the 12th International Conference on Data Engineering, New Orleans, Louisiana, USA.

Amaravadi, C. S. (1999). Planning for office information systems, Proceedings of the Information Resources Management Association (IRMA) May 17th, 20-27.

25

Amaravadi, C. S. (2001). Engineering administrative knowledge for extended office systems, Proceedings of the 2nd European Conference on Knowledge Management, Bled, Slovenia, Nov 7-8.

Amaravadi, C., George, J. F., Sheng, O. R. and Nunamaker J. F., (1995). The adequacy of office models. Advances in Computers, 40, 181-253.

Amaravadi, C., Sheng, O. R., George, J. F. and Nunamaker J. F., (1992). AEI: A knowledge-based approach to integrated office systems. Journal of Management Information Systems, summer, 9(1), 133-163.

Ang, J. S. K., Conrath, D. W. (1993). The Ithaca office object model: Modeling and Implementation, Database, November, 24(4), 5-14.

Ang, J.S.K., and Hong, J. (1994). AMS formalism: an approach to office modeling and OIS development, Database, November, 25(4) 25-38.

Attie, P.C., Singh, M. P., Emerson, A. E., Sheth, A.P., Rusinkiewicz, M. (1996). Scheduling workflows by enforcing intertask dependencies. Distributed Systems Engineering, 3(4), pp 222-238.

Auramaki, E., Lehtinen, E., and Lyytinen K., (1988). SAMPO: A speech act based approach to office modelling. ACM Transactions on Office Information Systems,April, 6(2), 126-152.

Barbic, F., Ceri, S., Braachi, G., and Mostacci, P. (1985). Modeling and integrating procedures in office information systems design, Information Systems, 10(2), 149-168.

Basu A., Blanning R.W. (1999). Metagraphs in workflow support systems, Decision Support Systems, April 25(3), pp. 199-208.

Bernal, M. (1982). Interface concepts for electronic forms design and manipulation. In N. Naffah (Ed.) Office Information Systems, (pp 505-518) New York: North Holland.

Casati F., Discenza A. (2001). Modeling and managing interactions among business processes. Journal of Systems Integration, April, 10(2), pp. 145-168

Celentano, A., Fugini, M. G., And Pozzi, S. (1991). Classification and retrieval of documents using office organization knowledge. ACM Conference on Organizational Computing systems, Atlanta:GA, November 5-8, pp. 159-164.

Christie B., (1985). Human factors of the user-system interface (pp. 23-70) New York: North Holland.

Chung, P.W., Cheung, L., Stader, J., Jarvis, P., Moore J., and Macintosh, A. (2003). Knowledge-based process management—an approach to handling adaptive workflow. Knowledge-Based Systems, 16(3) , 149-160

Clancey W.J.; Sachs P.; Sierhuis M.; Hoof R.V. (1998). Brahms: simulating practice for work systems design. International Journal of Human-Computer Studies, December , 49(6) 831-865

Conrath, D. W. and Ang J., (1987). Office modeling: comments about the present and the future. IEEE Technical Committee on Office Automation Newsletter, May 1(2), 2-10.

26

Corkill, D., Rubinstein, Z., Lander, S., Lesser, V., Live-representation process management. Proceedings of the 5th International Conference on Enterprise Information Systems, Angers, France, April 2003.

Davenport, T. H., Jarvenpaa, S. L., and Beers, M., C. (1996). Improving knowledge work processes, Sloan Management Review, Summer, 37 (4), 53-65.

Dellen B., Maurer F.., Pews G. (1997) Knowledge-based techniques to increase the flexibility of workflow management. Data and Knowledge Engineering, September 23(3) pp. 269-295

De Jong, P. (1987). UBIK: A system for conceptual and organizational development. In Lamersdorf (Ed.)

Office knowledge: representation, management and utilization, Proceedings of the IFIP, Toronto, Ontario, Canada August 17-19th, (pp. 19-36) New York: North Holland.

Desai, S. (1991). Unification of underlying concepts in different office models. DataBase, Winter, 22(1&2) 38-45.

Ellis, C. A. & Nutt, G. J. (1980). Office information systems and computer science. ACM Computing Surveys, March, 12 (1), 3-36.

Ellis, C. A., & Naffah, N. (1987). Design of office information systems, New York: Springer-Verlag.

Engel, G. H.; Groppuso, J.; Lowenstein, R. A.;, and Traub, W. G., (1979). An office communication system. IBM Systems Journal, 18(3), 403-431.

Eshuis, E., Wieringa, R. (2001). A comparison of petri net and activity diagram variants Proc. of 2nd Int. Coll. on Petri Net Technologies for Modelling Communication Based Systems, Berlin, September 14th-15th, pp. 93-104.

Faidt., K., and Karagiannis, D. (1990). Knowledge-based applications in office information systems: an integration approach. Database and Expert Systems Applications Conference (DEXA), Vienna, Austria, August 29-31, pp. 334-339

Garvin, D. (1997). The processes of organization and management. Sloan Management Review, 39(4), pp. 33-50.

Gerson, E. M. and Star, S. L., (1986). Analyzing due process in the workplace. Third ACM SIGOIS Conference Oct 6-8, Providence, Rhode Island, 70-78.

Grainger A.J.; Hide I.G.; Elliott S.T.; Nurcan S.(1998). Analysis and design of co-operative work processes: a framework, Information and Software Technology, June, 40(3), 143-156.

Grefen, P. (2002). A Taxonomy for Transactional Workflows, CTIT Technical Report 02-11, University of Twente.

Grundy, J. C., Hosking, J.G.., and Mugridge, W. B. (1998). Supporting large-scale end user specification of workflows, work co-ordination and tool integration, Journal of End User Computing, Spring, 10 (2), 38-48.

Hackbarth, Gary, and Grover, Varun (1999), The knowledge repository: organizational memory

27

Information Systems Management, Summer 1999, 16,3, 21-35.

Harper, D. J., Dunnion J., Sherwood-Smith, M., and Van Rijsbergen (1986). Minstrel-ODM: A basic office data model, Information Processing & Management 22(2), 83-107.

Jacobs, E. (ed.) (2001). Handbook of U.S. Labor Statistics: Employees, earnings, prices, productivity and other labor data, Lanham, Massachussetts: Bernan Press.

Johns, B. C. (1996) Experiences implementing workflow based systems in manufacturing enterprise product development and change processes. Report from the NSF Workshop on Workflow and process automation in information systems. Siggroup Bulletin, April, 18 (1).

Kamath M.; Ramamritham K. (1996). Correctness issues in workflow management, Distributed Systems Engineering, 3 (4), pp. 213-221(9)

Karbe, B., Ramsperger, N. G. and Weiss, P. (1990). Support of co-operative work by electronic circulation folders. Proeedings of the ACM Conference on Office Information Systems, 109-117.

Koubarakis, M., Plexousakis, D., (2002). A formal framework for business process modeling and design. Information Systems, 27(5), pp. 299-319.

Kreifelts T. And Woetzel, G. (1986). Distribution and error handling in an office procedure system. In Bracchi G. and Tsichritzis D. (eds.) Office Systems: methods and tools, Proceedings of the IFIP October 22-24 (pp. 197-208), Pisa, Italy.

Lamersdorf, W., Schmidt, J. W., Muller, G., (1986). A recursive approach to office object modelling, Information Processing and Management, 22(2), 109-120.

Loucopoulos, P., Mcbrien, P., Schumacker, F., Theodoulidis, B., Kopanas, V., and Wangler, B. (1991). Integrating database technology, rule-based systems and temporal reasoning for effective information systems: the TEMPORA paradigm. Journal of Information Systems, 1(4), 129-140.

Loucopoulos, P. and Katsouli, E. (1992). Modelling business rules in an office environment. SIGOIS Bulletin,August, 13(2), 28-37.

Lee R. (1988). Bureaucracies as deontic systems. ACM Transactions on Office Information Systems, 6(2) (April), pp. 87-108.

Lee R. M. (2002) Automated generation of electronic procedures: procedure constraint grammars Decision Support Systems, July, 33(3), pp. 291-308.

Liu D. R., Shen M. (2003). Workflow modeling for virtual processes: an order-preserving process-view approach, Information Systems, September, 28(6), pp. 505-532.

Lum, V. Y., Choy, D. M., And Shu, N. C. (1982). OPAS: An office procedure automation system. IBM Systems Journal, 21(3), 327-350.

Lycett, M. and Paul, R.J. (1999). Information systems development: a perspective on the challenge of evolutionary complexity. European Journal of Information Systems, June, 8(2), 127-135.

28

Malone, T. W., Grant, K. R., Brobst, S. A And Cohen, M. D. (1987). Intelligent information sharing systems. Communications of the ACM, May, 30(5), 390-402.

Mann, William C. & Thompson, S. A. (1988). Rhetorical structure theory: toward a functional theory of text organization. Text, 8(3):243--281.

Mann, M. M., Rudman, R. L., Jenckes, T. A. and Mc Nurlin, B.C., (1997). “EPRINET: Leveraging knowledge in the electric utility industry, in Prusak, L. (Ed.) Knowledge in Organizations, pp. 73-97. Butterworth-Heinemann: MA.

Mcfadden, F., Hoffer, J., and Prescott, M. (1999). Database management (pp. 53-55) (4th ed.). New York: Benjamin/Cummings.

McLeod, R. and Jones, J.W. , (1987). A framework for office automation. MIS Quarterly, March, 87-104.

Morgenbrod H. G., and Schwaertzel H. G. (1980). The degree of office automation and its impact on office procedures and employment. Computer Networks, 3-11.

Motiwalla, L. F. And Aiken, M. W. (1993). An organizational communications perspective on knowledge based mail systems. Information and Management 25, 265-272.

Ngu, A., Duong, T., and Srinivasan, U. (1996). Modeling workflow using tasks and transactions. Report from the NSF Workshop on Workflow and process automation in information systems. Siggroup Bulletin, Apri1, 8(1).

Ontoprise (2003). Semantics for the Web. [http:// www.ontoprise.com] current 2003.

Pernici, B. (1990). Objects with roles. ACM Conference on Office Information Systems, April 25-27, Cambridge, MA, 205-215.

Pernici B., Barbic F., Fugini M.G., and Maiocchi R., (1991 October). C_TODOS: An automatic tool for office system conceptual design. ACM Transactions on Information Systems, 7(4), 378-419.

Perlow, L. A., (1999). The time famine: Towards a sociology of work time, Administrative Science Quarterly, 44, 57-81.

Poppel, H. L., (1982). Who needs the office of the future? Harvard Business Review, (Nov-Dec), 146-155.

Preuner G., Schrefl M. (2000), A three-level schema architecture for the conceptual design of web-based information systems: from web-data management to integrated web-data and web-process management, World Wide Web, 3(2), 125-138.

Quinn, J. B., Baily, M. N., Herbert, G. R., Willett, D., (1994). Information technology: Increasing productivity in services;Executive commentary, Academy of Management Executive, August 8(3), 28-5.

Ram, S., Park, J. and Lee, D. (1999). “Digital libraries for the next millennium: challenges and research 29

directions,“ Information Systems Frontiers, 1(1), pp. 75-94, July.

Retallick, R., and Sanchez, S., (1998). Enterprise knowledge sharing, activity management, and a fabric for commitment, IBM Systems Journal, 37(2), 189-199.

Riddle, W., E. (1996). Fundamental Process Modeling Concepts. Proceedings of the NSF Workshop on Workflow and Process Automation in Information Systems: State of the Art and Future Directions, Athens, Georgia, May

Rosner, D., Grote, B., Hartman, K, Hofling, B, Guericke, O. (1998) From natural language documents to sharable product knowledge: a knowledge engineering approach. in Borghoff Uwe M., and Pareschi, Remo (Eds.). Information technology for knowledge management. Springer Verlag, pp 35-51.

Rouncefield, M., Hughes, J.A., Rodden, T., and Viller, Stephen (1994). Working with “constant interruption”: CSCW and the small office, in Proceedings of the ACM Conference on Computer Supported Collaborative Work, Oct 22-26, 275-285.

Sadiq W., Orlowska M.E.(2000). Analyzing process models using graph reduction techniques,Information Systems, April 25(2), pp. 117-134.

Scacchi, W. (1996). Modeling, integrating, and enacting complex organizational processes: Approach and Experience. Report from the NSF Workshop on Workflow and process automation in information systems, SIGGROUP bulletin, April 18(1), 23.

Schultze, U. (2000), A confessional account of an ethnography about knowledge work. MIS Quarterly March 1 2000 24(1), 3-30

Sheth, A. (1997). Report from the NSF Workshop on Workflow and process automation in information systems, SIGGROUP bulletin, April 18(1), 23.

Sowa, J. F., Conceptual Structures: Information Processing in Mind and Machine, Addison Wesley, 1984.

Suchman, L. A. (1983) Office procedure as practical action: models of work and system design, ACM Transactions on Office Information Systems, October, 1(4) 320-328.

Sutherland, J. and Willem-Jan van den Heuvel (2002) Developing and integrating enterprise components and services: Enterprise application integration and complex adaptive systems Communications of the ACM, 45, 59-64.

The, Le (1994 October 1), Getting into the workflow, Datamation, 40(19), 65-72.

Thachenkary, C. S., and Conrath, D. W., (1982). The office activities of two organizations. In N. Naffah, N. (Ed.) Office Information Systems. 452-469. New York: North Holland.

Tsichritzis, D. (1982 ). Form management. Communications of ACM, July, 25(7) 453-478.

Vail, Edmond, F., (1999), Knowledge mapping: getting started with knowledge management, Information Systems Management, Fall, 16(4), 16-23.

30

Wang, J. T. L. and Ng, P. A. (1992). TEXPROS: An intelligent document processing system. International Journal of Software Engineering and Knowledge Engineering, 2(2), 171-196.

Workflow Management Coalition (1998), Interface 1: Process Definition Interchange, Document # WFMC-TC-1016-P. [http://Wfmc.org].

Yao, B. S., Hevner, A. R., Shi, Z. and Luo, D. (1984). Formmanager: An office forms management system.

ACM Transactions on Office Information Systems, July, 2(3) 235-262.

Yang, J. (2003), Web service componentization: towards service reuse and specialization, Communications of ACM, October, 46(10), 35-40.

Zack, Michael H., (1999) Managing codified knowledge, Sloan Management Review, Summer 40(4), 45-58.

ENDNOTES

31