WorkMail: collaborative document workflow management by email

WorkMail: collaborative document workflow management by email Davide Gazz´e, Mariantonietta N. La Polla, Andrea Marchetti, Maurizio Tesconi, Andrea Vivaldi Institute of Informatics and Telematics National Research Council (CNR), Pisa, Italy

Abstract. Processing documents is a critical and crucial aspect for enterprises. The management of documents involves several people and can be a long and time-wasting process. We developed a document workflow engine based on email paradigm. Exploiting a web application, the subject of the workflow, the document, can be sent as an email attachment. Our solution overcomes the current limitation in the use of Document Workflow software, especially regarding user experience. With our system there is no need for users to learn how a new framework works. In addition, users with different roles have different customized view of the document. Moreover a suggest feature has been implemented; the system suggests a possible receiver for the document, depending on the document flow.

Keywords: Documental Workflow, Web Technologies, Web based cooperation tools, Office Automation, Information Management

1

Introduction

The problem of processing documents is a critical aspect in the enterprise productivity ([1],[2], [3], [4], [5] and [6]). The management of documents involves different actors with different roles, the possibility of decentralized working environment, different tasks and responsibilities. Enterprise operations can be viewed as a series of steps involving the filling out of a form representing the document, often in concurrent manner. It is possible to define all these kind of activities related to documents as Document Workflow (DW). In general, a workflow is “the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” [7]. With the term Document Workflow we refer to a particular workflow in which all activities are related to document’s compilation [1]. Therefore, a DW can be viewed as the automation and administration of particular document procedures ([8], [2] and [6]). Through a DW, a document life-cycle is tracked and supervised continually and the document travels among agents who essentially carry out the pipeline receive process and

send activity. With these features, a DW can solve problems related to document management in enterprises. The paper is structured as follows: Section 2 reports a brief State of the Art concerning different types of Workflow Management System and a discussion of the limits of existing practices. Section 3 presents our solution with an example of application of WorkMail in a real case. Section 4 draws the conclusions and discusses future works.

2

State of the art

Over the past years different workflow management systems (WfMS) have been developed, but as explained in [9] and in [10], they lack of a standardized background theory, that can play the same role of relational algebra for databases. However, according to [11], it is possible to classify the modeling methods of existing WfMs as follows: Structured and Ad-Hoc. In the structured model the information needed for the definition of the workflow can be retrieved from the analysis and the modeling of the real process. This is due to the fact that, this kind of process, never or not often changes after its definition. However, in real cases, there are exceptions and some parameters cannot be defined a priori: this is the key idea of the ad-hoc model, which has the same characteristics of structured model, but includes the treating of less repeatable situations. Document-centric or Process-centric. As the name suggests, Documents-centric WfMSs have as key factor the document and its circulation between people. The document can be also images, like in the existing Imaging Processing Systems. On the other hand, Process-centric WfMSs consider business process as a series of interdependent steps. At each step, data are processed using specific application tools, invoked either by the user or by the system itself. Data produced at each step represent the input of the subsequents steps. Email-based or Database-based. The email based WfMSs use email system for message routing, data distributing and event notifying during the execution of a process instance. These WfMSs are typically used by many low-end systems. Database-based WfMSs store all the data (including application data) needed in a DBMS. In these WfMS the instance execution is the process of retrieving and processing data stored in the DB. Task-pushed or Goal-pulled. Task-pushed WfMSs execute activities in a process one-by-one. An activity is created only if the previous one is terminated. After all the activities have been completed, the process is considered completed. Task-pulled WfMS are usual implementation of most process-centric WfMSs. Goal-pulled WfMSs resolve the entire process as multiple interdependent executable steps that need to be performed in order to obtain a goal (the process).

Each step can be viewed as sub-goal. When all sub-goal are terminated, the process can be considered finished. Nowadays there are many web-based tools for the definition of document workflow (often named Enterprise Content Management-ECM). ECM refers to solutions that combine conventional tool for Content Management and webbased components and that performs traditional archive, document management and workflow functionalities [12]. As examples, we can mention Alfresco1 or Nuxeo Enterprise2 : in these software documents can be shared or modified cooperatively, exploiting shared folders (like Google Drive folders). However, offered capabilities are too basic, in terms of supported workflow patterns and design, to serve specific and sophisticated needs. Concerning document workflow system, not ECM solutions, an example is Doqui3 , an Italian open source project targeted to the public administration offices. Others examples are Cuteflow4 , an open source workflow system that enables document circulation, and DocMGR5 , a web-based Document Management System. 2.1

Limits of the Document Workflow Systems

As said in [13], the workflow system categorizes, formalizes and automates work that often has a fluid and unpredictable nature. Many empirical studies by Joostens [14] relates workflow management to the organizational structure type defined by Mintzberg [15] stressing that, in addition to the positive impacts, there are many possible negative aspects [13]. The nature of that includes rigid procedures, reduction of learning by employees (because the steps are pre-programmed), reduction of motivation of a worker (his work becomes more mechanical) and, finally, the underestimation of the importance of human communication. Production and administrative Workflow Management System are suitable for routine situations [16], but not in the area of knowledge work. This because it is not possible to define a precise flow beforehand and there is a need for communication and collaboration between workers. In this case actors choose their next steps one at time so it is very important to have a more flexible system. However, there are some works such as [17], that try to provide an environment supporting an advanced form of coordination in a cooperative environment, introducing flexible execution.

3

Document workflow by mail - WorkMail

To design an efficient DW engine we started from some key aspects: (i) we needed a simple tool for collaborative document elaboration; (ii) one of the most used tool in an enterprise environment is the email. Emails are very useful 1 2 3 4 5

http://www.alfresco.com http://www.nuxeo.com http://www.doqui.it http://www.cuteflow.org http://www.docmgr.org

in organization environment due to several reasons: users can provide quick answers, easily communicate with each other (without physically meeting), or distribute documents and information in an easy and paperless way. But the email paradigm is not sufficient to manage a DW. Despite these advantages, we had to take in account some drawbacks: emails are impersonal and could often be misunderstood; answering complicated questions could be a time-consuming task. Moreover, attachments cannot be modified after they are sent. We use the paradigm of email as base for a new approach for a document workflow system: WorkMail. WorkMail is a web-based application that tries to combine the potential of a DW with the flexibility of an email; in this way we exploited the advantages of the paradigm and overcame problems related to the above-mentioned drawbacks. The document and his modification are key aspects of WorkMail. In our solution, a document is used as attachment of an email that moves from one person to another one. In WorkMail the document is a special attachment: it is composed by different editable fields. Depending on his role, different users can visualize and modify, at each step, different fields of the document. This represents one of the most valuable advantages of using WorkMail: the attachment is unique. WorkMail is developed as a transparent system: this means that, if a user modifies and re-accesses a document that was further modified by other users along the workflow he will be able to see the new modifications. However, it is possible to adapt the system for situations in which a user can visualize only an intermediate version of the document and he is forbidden to see further versions of the document that is modified later in the workflow. To modify a document, it is not necessary to create a new one and attach the revised version as new attachment, but users can modify the existing one. Figure 1 shows the base concept of WorkMail. In WorkMail users are important also for the role played in the company or in the organization. Every enterprise, organization or company have an organization chart that provides information about employees and their assignment and responsibilities. Typically, these distinctions are according to the considered office: for example, employees in the administrative office have different responsibilities from human resource staff. Furthermore, in the same staff it is possible to distinguish between directors, employees, assistants, etc. We use these differences between users to handle the document and his fields. 3.1

Architecture and Implementation

In order to implement our solution, we have designed the architecture shown in Figure 2. The core of the architecture is the WorkMail engine that manages all the actions involving the shared document, such as the definition of the permission set. The Document Manager component creates the template of documents and is used to manage the lifecycle of a single document (create, read, update and delete). The User Role Access Control enables managing the access to the system

Fig. 1. Conceptual Idea.

Fig. 2. WorkMail architecture.

according to user and his roles. The Template is used to adapt the view of the entire document, according to the user’s role. The Access Description Path allows or denies dynamically the access to a particular field of a document based on different parameters: – – – –

user; user’s role; type of document; step of document workflow.

The Workflow Description is a set of rules that describes the document workflow in term of users, roles and document. WorkMail has been developed using open source technologies like Apache, PHP and MySQL. We chose Drupal6 as content management framework for its high 6

http://drupal.org

modularity. Figure 3 shows the implementation of WorkMail. CCK is a module of Drupal that enables the creation of any kind of structured document.

Fig. 3. WorkMail implementation.

We model every document in the workflow system as a new content type. Every content type is fully configurable so we can add or remove fields, set the type of these fields and set different permissions per fields in the same document. Moreover, fields and content types have own properties, like information about the author and the timestamps of creation and modification. To categorize the email content type the Drupal’s Taxonomy is used. Users and roles are managed by Drupal core. Every user can have one or more roles and the permission setting is connected directly with a role. In this way, if a certain user performs an action we need to assign a specific permission to a role and then the role to the user. The first fundamental concept of the engine is the shared document to fill out (the attachment of the workmail). An instance of content type is called node. The attachment node is unique in the whole document workflow, so users edit the same instance of the document collaboratively; each user edits only his own part of the document. To implement this feature we need a container to deliver the shared document between users, so another content type has been created to contain the attachment. This new content type (workmail) has as many instances as the number of users involved and performs the role of the classic email. The workmail content type contains data about the recipients, the object, the body and other flags indicating if an email is read or not. When a user creates an email with a document attached the engine creates: – workmail content types for each user in the recipient; – a single attachment content type. A user creates new workmail content types also when he replies or forwards the email attachment. To make document’s editing really cooperative, different permissions to different roles can be assigned to every single field in the document configuration. Every attachment node has not a prefixed permission setting,

because in our case the flow is dynamic and not static. So the engine is capable of calculating the right permission at runtime, depending on the content of the recipient field. We only need to preset generic roles with generic permissions on the document’s field; the engine dynamically associates users to these generic roles during the document flow. The User Interface looks like a web-email client (like GMail, Yahoo mail, Microsoft mail, etc.). While the InBox and SentBox are similar to those of standard email clients, the Compose Tab is different. Differently from standard email clients, a section containing suggested attachments is presented. When a user chooses the type of the attachment, the system shows an instance of the document that the user can fill out. The visibility of each field of the document and his proprieties (readable, editable) depend on the user and on the step of the flow. After saving, the user can see the attachment in the compose area. Optionally the user can specify one or more tags on the field TAGS enabling the categorization of emails in folders. A vocabulary of tags is associated to the content type. For instance, if a user starts a Travel Request, as in our example of application (see Section 3.2 for more details), he must click on the corresponding label. Moreover, for what concerns the ‘To’ field, differently from emails, the receiver can be either another user or role: this can be useful when a document has to reach a group of users with a specific role such as the administrative office. Even if the receiver is a role, the system will resolve the role in relation to the sender. One of the innovative features of WorkMail is the suggestion method. When a user has to send a document to someone, the system suggests a list of possible receivers; this information is stored statically in the system database (see Section 4 for further details). In case of wrong recipient, users can manually change the email; this ability simplifies human actions, so a user can decide to follow the proposed flow or change it dynamically. 3.2

Example of application

To illustrate the usefulness of our solution, we propose an example of usage. We consider as case study the process of a travel request (T.R.) in our research institute, the Institute of Informatics and Telematics of National Council of Research, Italy. In our scenario an employee that has to travel for a conference or a meeting, has to start a procedure of travel request. This procedure involves: – – – –

the the the the

employee’s manager for a preliminary authorization; administration office for what concerns the budget effort; director for the final authorization; human resource office for closing the procedure.

The flow related to this procedure is summarized in Figure 4. In each phase of the process, users have to fill a travel request document, providing different kinds of information. The key aspect is that some of these information are known only by specific users with specific role. For instance, the information about budget

Fig. 4. Travel Request flow.

are provided by the administration office because these are information that an employee does not know. This is a typical example of collaborative editing of a document. If the same procedure was performed using the standard email, at each step, the user had to – – – – –

4

read the current version of the document; create a new document with the already known information; fill out the fields of the document needed at this step; attach the new version of the document; send the email at the next user.

Conclusion and Future works

In this paper we presented WorkMail, a new approach for document workflow system which overcomes the limitations of the current document workflow software. The benefit that our model includes is twofold. From a user’s point of view, the use of the email paradigm is helpful to learn using the document workflow system. Due to the fact that we exploit the email paradigm, users can use WorkMail easily, without learning anything about the functioning of the system. They do not need to learn how to use a new document workflow system but can continue to send emails with attached documents as usual; therefore, starting to use WorkMail is not a wasting time process. From a system’s point of view, WorkMail encourages people for collaboration and it is exception free; this is due to the fact that the user will manage the flow, choosing the receiver of the document at each step. Moreover, we want there is the advantage of using this system as a paperless way to manage documents.

Even if our approach can solve different problems, many technical aspects can be improved and some new features can be developed. First of all, it should be possible to define an end state for the document: this is the case of documents that are completely compiled. It is also possible to extend the search area for filtering a workmail according to sender user, type of attachment, data and tags. It should be possible to add a feature for digital signature: in this way, documents generated by WorkMail can get legal effect. A very interesting and most innovative feature that we are planning to implement is a smart suggestion mechanism. This mechanism will suggest to the user, for each kind of document and for each step of the flow, who could be the receiver of the email. We will perform a statistical analysis of different information, like involved users, roles, type of attachments and step of the flow, to determine the frequency of the relationship between a sender and receiver, regarding a particular attachment. Obviously, the engine will need some time to learn the flow and then the receivers to be suggested, so it will be possible to provide a learning mode for the first time. In case of significant changes of a flow, it is possible to restart the learning process for specific type of attachments.

References 1. Marchetti, A., Tesconi, M., Minutoli, S.: Xflow: An xml-based document-centric workflow. In Ngu, A., Kitsuregawa, M., Neuhold, E., Chung, J.Y., Sheng, Q., eds.: Web Information Systems Engineering WISE 2005. Volume 3806 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg 290–303 2. Krishnan, R., Munaga, L., Karlapalem, K.: Xdoc-wfms: A framework for document centric workflow management system 3. Kappel, G., Rausch-Schott, S., Reich, S., Retschitzegger, W.: Hypermedia document and workflow management based on active object-oriented databases. In: System Sciences, 1997, Proceedings of the Thirtieth Hawaii International Conference on. Volume 4. (jan 1997) 377 –386 vol.4 4. Baresi, L., Casati, F., Castano, S., Fugini, M.G., Mirbel, I., Pernici, B.: Wide workflow development methodology. SIGSOFT Softw. Eng. Notes 24(2) (March 1999) 19–28 5. Casati, F., Grazia Fugini, M., Mirbel, I., Pernici, B.: Wires: A methodology for developing workflow applications. Requirements Engineering 7 (2002) 73–106 10.1007/s007660200006. 6. Georgakopoulos, D., Hornick, M., Sheth, A.: An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel Databases 3 (1995) 119–153 10.1007/BF01277643. 7. Buhler, P.A., Vidal, J.M.: Towards adaptive workflow enactment using multiagent systems. Information Technology and Management 6 (2005) 61–87 10.1007/s10799004-7775-2. 8. Marchetti, A., Minutoli, S., Lazzareschi, P., Martinelli, M.: System for managing documents in a step by step process. In: XML World Euro Edition. (2001) 9. Haller, A., Oren, E., Petkov, S.: Survey of workflow management systems (2005) 10. Aalst, V.D.: The application of petri nets to workflow management (1998) 11. Meilin, S., Guangxin, Y., Yong, X., Shangguang, W.: Workflow management systems: A survey. In: in Proceedings of IEEE International Conference on Communication Technology. (1998)

12. U., U.K.: Definitions, scope, architecture, components and ecm-suites in english, french, and german. (2006) 13. Suchman, W.: At workflow automation,overview and research issue 14. Joosten S, Aussems G, D.M.H.R.M.E.: An empirical study of the practice of workflow management (1994) 15. Mintzberg, H.: Structure in fives: designing effective organizations (1983) 16. Stohr, E.A., Zhao, J.L.: Workflow automation: Overview and research issues. Information Systems Frontiers 3(3) (September 2001) 281–296 17. Grigori, D., Charoy, F., Godart, C.: Flexible data management and execution to support cooperative workflow: the coo approach. In: Cooperative Database Systems for Advanced Applications, 2001. CODAS 2001. The Proceedings of the Third International Symposium on. (2001)