Collaborative Business Applications: A New Methodological Approach

Introduction

The main goal of the adoption of the social networking in the business environment is to provide an added value to the company as reported in the research work of Schmidt (2009) through the creation of a knowledge base able to describe and to manage all the information that are usually not structured. McAfee (2006) had foreseen more and more the structured use of the collaboration between the employees; in fact, many companies are quickly changing in order to acknowledge the principles of the E2.0. Clearly, these new principles affect mainly the business processes that must be re-thought of to maximize the benefit of the E2.0 paradigm.

Considering the academic definition, a business process is a set of correlated activities (carried out inside the company) that  create  value    through    transforming resources (input) in a product (output) destined to a subject inside or outside the company (customer). To optimize a business process, means to diminish the costs, to reduce the times and to improve the production.

If in the 1910, the optimization of the production processes was realized introducing the assembly line, from the nineties of the past century, the optimization is achieved through the evolution of the business processes that implements complex strategies. In particular, today, many companies are spending in a project of Business Process Reengineering and of integration of information systems in order to improve their efficiency. There is not a best way to optimize the company; but in each optimization strategy, the first phase always involves the modeling of the business processes.

To model a business process, means to represent it through suitable graphical modeling language with its notation and rules. The use of a complete language (that provides also a graphical notation of the processes) simplifies the work of the designer who has to analyze, to understand, to monitor and to redesign the process in order to optimize it. Furthermore, the graphical notation helps the ICT designer (without a specific skill in the design of the business process) to define the requirements of the software that has to implement the processes. The process representation is so important that is considered a part of the inner and external communication of a company and allows sharing information between the company levels: from the analysts to the employees and to the technicians, and also from a company to another.

The Business Process Modeling Notation (BPMN) is the standard de-facto in modeling of the business processes and in February 2006, was adopted as standard also by OMG. The main goal of BPMN, as reported in Business Process Modeling Notation version 2.0 (2009), is to supply one notation easily understandable and suitable to all the business customers. BPMN 2.0, its second version of the notation, is born to introduce new concepts such as “Choreography” and “Conversation” in order to manage the explicit collaboration between the actors. The notation proposed by BPMN2.0 cannot be considered as an appropriate solution for the representation of the collaboration paradigm of the E2.0.

In E2.0, the collaboration between the employees is seen as a cooperation to solve the same task sharing the knowledge; while, the Enterprise 2.0 from the perspective of BPMN can be seen as a sequence of activities, performed using technology, which involve “at the same time or not” more than one actor. In other words, BPMN is focused on the concept of workflow, while in E2.0 the main idea is the knowledge sharing.

In order to model the knowledge sharing, Hawryszkiewycz (2009) had proposed customized approach not using BPMN but designing an infrastructure to support the collaboration. The result is a representation of a flow but without the powerful notation of BPMN. Other researchers as Erol et al. (2010) affirm that the mix of Business Process Modeling and social software offers several benefits but they consider only the business process that may be executed without a predictive flow, such as those processes that have a higher level of creativity (analysis, design, etc..); while the more traditional business process can be treated in the usual way using a workflow management engine. Of course, we totally agree with Erol et al. (2009) that there are a lot of activities that could have a lot of benefits if they are taken out from the workflow.

Our approach, instead, is based on the idea that it is possible to improve the performance of the business process by introducing the new concepts (derived by collaboration aspects) on the workflow business process. These new concepts, on one hand, model the collaboration describing the knowledge sharing and on the other allow representing the collaborative tools that are able to implement the collaboration. In our model, the BPMN design, that is an added value for the company, is simply considered a set of requirements on which the collaboration must be implemented.

In this paper, in the second section, we provide a brief description of the methodology.  Then, in the third section, we provide a real case study about the Finance Sector describing the effect of the application of the methodology to model the basic concepts of Enterprise 2.0.

Description of Methodology

Considering the complexity of the introduction of Enterprise 2.0 paradigm, the company must evaluate with extreme caution the actions to apply in order to avoid the governance problems and to minimize the risks of change management. Thus, it is important that this change will be supported by a structured approach that allows planning correctly the collaborative aspects between the employees to plan how the business process will change and the more suitable collaborative tools able to capture the knowledge sharing. 

In the research study by Paiano et al. (2010), the proposed path to introduce the E2.0 [6] is composed by several steps that affect all the enterprise area from the monitoring and planning area that deals with management and governance to the operative sector that encourages the cooperation and collaboration in the horizontal and the vertical process. In every case, independently by the adopted introduction procedure, there is the need to introduce new concepts in the design of the business process in order to consider all the collaboration aspects that are not included in the BPMN2.0 notation. On this basis, we have analyzed the effective collaboration in Enteprise2.0 paradigm and we have defined two kinds of processes: first the processes strictly connected with the workflow concept (the fundamental idea of the BPMN notation); second the collaborative processes in which more users can cooperate into the same task to reach the same goal.

This last kind of process does not have a predefined sequence of tasks (lack of workflow) but requires that several tasks will be completed to reach the specific goal. The proposed methodological approach allows modeling both kinds of process. The processes without workflow are modeled through the creation of a specific diagram named Collaborative WorkSpace which its main goal is to define the context (or the space) of collaboration between the users and the tasks that must be completed to reach the goal. With the collaborative workspace, the designer can model all the phases of the process that are not covered by a real workflow but that are executed by the actors. Before the introduction of the Collaborative WorkSpace, the designer had two options to describe this set of tasks: to force them into a pseudo-workflow really far from the real user activities or not to consider them.

The Collaborative Workspace (CWS) is a piece of a process that can coexist with the other pieces governed by the workflow. For example, in figure 2 where a process that concerns about a loan is described, and it will be detailed in the section 3, the first contact and the preliminary investigation are CWSs because these activities could be more effective, if they are not tied into a predefined workflow.

Collaborative Workspace

A Collaborative Workspace is characterized by a set of tasks executed by two or more actors through the tools of the Web 2.0. These tasks are weakly connected between them, and the user can execute them without a predefined order (without workflow).

The designer, to define a collaborative workspace, must model:

(i)    the involved actors,

(ii)    the collaborative tasks,

(iii)    the input information to start the user interaction in the collaborative workspace;

(iv)    the goal to complete that is also the exit point of the collaborative works

The notation of CWS is shown in figure 1.

Fig 1. Collaborative Workspace Notation

 
The previous figure represents a phase of the process about the request of permission to build. In detail, figure 2 describes the phase in government authorities where they shall acquire the opinions from a set of subjects. In Italy, this is a standard procedure. Using the collaborative vision between the involved actors is possible to completely redraw the process favoring the parallelism between the tasks, in agreement with the principles of the BPR.

The involved government authorities who have to release the building permission are: the SAE (the office that manages the building permit) that will send requests of opinions to the ASL (Local health authority), to the STVP (Technical Service Projects Evaluation) and to the District Council via email.

The STVP supports its employees (that has to consult references about the building regulations and at several other specific regulations) with tools such as WIKIs (that contains the current rules and old case studies about the application of the same rules) and Forum (to interact with experts in order to solve not plain cases).

The ASL expresses its reference opinion in matters of hygiene housing according to the local hygiene regulation and the state health laws; furthermore, in this activity, the collaborative tools such as wikis and forum are used.

After acquiring the dossier, the District Council has to express an opinion on the request as planned by the regulation of the district. Such activities could be turning through video conference and it may be recorded, using tags, and attached to the dossier through bookmarking.

At the end of every activity, each unit makes the TAG and the bookmarking to their own work. Furthermore, each involved government authority responds to SAE through email communicating its expressed opinion that updates the dossier. 

At this point, the SAE will update the applicant about the state of its request through RSS.

Collaborative Business Processes

In order to correctly introduce the E2.0 model, it is necessary to detail the collaboration level of each process task. For this reason, we classify the activities in the following categories:

• Collaborative activities: if during their execution, they involve more than one user who cooperates using the collaboration tool such as blog, chat

• Semi-collaborative or “knowledge sharing” activities. This kind of activities is executed by a single user who uses information sources and tools such as the document sharing, instant messaging, blog to acquire information about his/her tasks. These tools allow sharing quickly and effectively the knowledge between the actors. In every case, these activities do not provide a direct cooperation to be executed.

This classification is fundamental during the re-design of the business processes and will be applied in the first steps of the methodology.

The presented approach proposes several steps that allow evolving the standard business process (based on the workflow) to a new collaborative version based on the E2.0 paradigm. Of course, the sequential application of all steps may be changed, according to the complexity of the application domain. In the following, we describe the methodological steps:

     1. Analysis and Classification of activities.

In this phase, the designer analyzes the current process in order to define the collaborative aspects. Its informal output (in a table) is the refinement of the As-Is model that has the goal of:

(i) discovering among the existing activities that can be executed in more effective way through the collaboration;

(ii) defining the new collaborative activities that can improve the performance of the process.

At the end of this phase, each activity is classified as collaborative, semi-collaborative and no-collaborative.

     2. Revising the AS-IS design.

In this phase, the new activities are reported on the BPMN diagram using the “task loop” and “message flow”. Thus, it is possible to have a complete view of the activities into the BPMN diagram in order to discover the collaboration inside the entire process and not only specific activities as in the first phase. The output of this phase is the basis for the next one.

     3. Customization of the Collaborative Activities.

In this phase, for each collaboration activity, the specific collaboration tools will be defined without considering the implementation aspects. The mapping between the activities and the collaboration tools is based on a specific thesaurus of collaborative tools. Considering that the specific collaborative tool is related to the specific task, it is necessary to define the scope attribute. The scope describes the rule of visibility and of use of the specific tools. In our approach, it can have the following value:

• Corporate: this scope is used to model the tool in which the managed information are visible to all the employees of the company that can share their knowledge and can express their opinions.

• Area: this scope is used when the information of the tools must be managed and seen by a restrict groups of employees such as all the project managers, all the secretaries or all the employees of a specific company sector.  
• Process. The tools that have this scope allow the access to the managed information only to the figure involved in the process. If the designer needs to allow the access only to a restrict group of actors of the process, he/she can use the scope process role that is a specialization of scope process. While if it is necessary to limit the contents managed by a specific role, it is possible to use process instance that allows accessing only to the information of the specific data of the process.  

At the end of this phase, for each collaborative tool the scope will be defined in each process in which is used. In fact, a specific collaborative tool could be used in several business processes with several scopes.

       4. Direction for use of collaborative mode.

In this phase, the complete diagram with the specific collaborative tools is produced. Here, for each collaborative tool (define by tool type and scope) the designer has to define the roles and for each role the rules of usage (such as write, read). At the end of this phase, each collaborative tool is defined by id (unique identifier). The id is unique in all the business processes while the scope of the tool is specific of the activities in which is used. Thus, a global view of the usage of the tools by several activities is provided.

Case Study Description 

In this paragraph, we illustrate a case study by which we demonstrate the application of the new methodological approach for describing collaborative dynamics into business processes. The process that we selected as a case study is named C.Q.S. (“Cessione del Quinto dello Stipendio”, in Italian). The C.Q.S. is a particular kind of loan used in Italy by which a financial institute (the lender) lends an amount of money to a private borrower (the customer) working for a public or private institution by means of a contract for a permanent position. The loan is based on an agreement between the financial institute and the organization the customer works for which states that the amount of the loan will be returned to the financial institute by paying one fifth of each customer’s monthly salary. The monthly payment will last until the amount of the loan plus the accrued interests will be reached.

The C.Q.S. process involves the following classes of stakeholders:

• the borrower, i.e. the customer asking for the loan;

• the lender, i.e. the financial institute providing the C.Q.S. loan service;

• the administration, i.e. the organization the borrower works for;

• the insurance company, which is asked to insure the loan.

The C.Q.S. process implies a prior administrative procedure aiming to ensure if the customer has the minimal necessary requisites for obtaining the loan. In this case study, we concentrate our attention on that prior administrative procedure, not on the following effective lending phase.

The following picture shows an overview of the C.Q.S. macro process flow in BPMN, as applied in an Italian financial institute which is the process owner.

Fig 2. The C.Q.S. Macro Process Flow

 
In detail, the single macro-tasks are:

• First contact: it is the starting phase of the process, in which one person who is willing to obtain a C.Q.S. loan, contacts the financial institute’ Call-Centre in order to ask for more detailed information and take an appointment with a seller. The seller is the intermediary figure which will take care of the customer relationship during all the process preliminary phases;

• Application form: after the first meeting with the customer, the agency officer collects all data necessary to fill in the application form and to start the procedure for that customer;

• Preliminary investigation: the financial institute analyst executes a  preliminary investigation about the loan on the base of all data collected during the application form’s filling phase;

• Final resolution: on the base of the preliminary investigation outcomes, the decision-making body takes the final decision about the loan;

• Contract effectiveness: all involved stakeholders are notified about the final resolution.

Considering the entire flow, it is possible to highlight many sub-flows that could be improved taking advantage of the collaboration between stakeholders. In this article, we concentrate our attention on First contact and Application form phases describing them by  BPMN AS-IS diagrams and then explaining how the new methodological approach could be applied.

The following picture represents the First contact AS-IS flow:

Fig 3. The AS-IS of First Contact Sub-Process Flow

Stakeholders involved in the First contact sub-process are the financial institute and the customer.

The customer interested in a C.Q.S. loan contacts the financial institute through Call Center. The Call Center operator receives the customer request and starts an interview in order to identify customer needs and gather his personal and job information (Information request, Providing information). The operator records all gathered information in the customer form (Request registration).

The operator, after having identified the nearest customer agency (Agency choice), proposes to the customer an appointment with one of the financial institute sellers who will provide the necessary counseling useful to clarify the loan terms (Appointment planning, Availability communication). The operator records the appointment agreed on the customer form (Appointment registration) and also specifies the list of documents the customer will have to bring with him during the meeting with the seller.

Then the agency officer, to whom the customer has been assigned, is asked to appoint the seller who will meet the customer (Seller assignment).

During the appointment:

• the seller asks the customer further information about their needs and all necessary documentation. The customer, at the same time, asks information about the procedure to follow (Information request, Providing information);

• the seller registers the documentation supplied by the customer during the appointment (Documents registration).

Finally, the seller registers the outcome of the appointment with the customer (Outcome registration), which will determine the starting or not of a new C.Q.S. instance. In a successful case, the macro-process flow continues with the “Application form” phase, on the contrary, the process stops.

The following figure represents the Application form AS-IS flow:

Fig 4. The As-Is of Application form Sub-Process Flow

The stakeholders involved in the Application form sub-process are the financial institute, the customer and the administration. In the first part of the sub-process, the agency officer registers, all the information about the customer and his request. As a first step, the agency officer having the customer in charge, starts filling out the customer personal data sheet (Personal data registration).

After that, he executes the following set of tasks in any order:

• collection and registration of all required documents (Document registration);

• registration of loan data (Request registration);

• registration of salary data (Salary data registration);

• registration of other outstanding loans  (Outstanding loan registration) declared and documented by the customer, if any;

• asking the administration for the amount assignable to the customer (Assignable amount request). That request is a preliminary activity, and the response may not arrive in the Application form phase. In any case, the amount assignable information cannot represent a block for the process flow.

After this first registration phase, the agency officer carries out the verification of the completeness of the information collected (Verification of information completeness). For the reason explained above, the amount assignable data is not considered in the information completeness evaluation. In case of lack of information, the agency officer notifies it (Integration request) to the seller who in turn asks the customer (Information request) for the necessary integrations. The customer provides (Providing information) all data requested to the seller who sends them to the agency officer. The officer then uses all data sent by the customer to complete the application form.

When the verification task gives a positive outcome, the agency officer goes to the next phase of the C.Q.S. process, i.e. the Preliminary investigation sub-process.

It’s worth underlining that the illustrated C.Q.S. process refers to the procedure in use by one Italian financial institute until May 2010. The financial institute is nowadays thinking about a process reengineering, by leveraging some concepts of the enterprise 2.0 approach. Next paragraph illustrates a first attempt to apply collaboration principles to First contact and Application form sub-processes, following the new methodology guidelines.

Application of the New Methodology: Collaborative Workspace

In this section, we illustrate how we applied the new methodology approach to the First contact sub-process.

First contact execution flow is a highly procedural sequence of activities supported by a workflow oriented software environment. The process owner experience demonstrated that the strict activities execution order and the separation between each stakeholder task represent a much more software constraint than a real requirement; this becomes a restriction which often limits stakeholders’ possibilities then reduces process performances.

These considerations suggested applying the “Collaborative Workspace” concept in modeling the collaborative version of First contact.

The following figure illustrates the “First Contact Collaborative Workspace”:

Fig 5. First Contact Collaborative Workspace

 
Stakeholders involved are: the customer, the Call Center operator and the seller.
Workspace tasks are:

• “Contact” which is the event triggering the workspace (input task);

• “Information registration”: the Call Center operator and the customer fill personal and job information. They can consult a wiki on how to fill the customer form and can communicate by blog, audio conference or messenger;

• “Agency choice”: the Call Center operator identifies the agency to which the customer has to be referred. The operator can consult a wiki on how to choose the agency;

• “Documents list definition”: the Call Center operator defines the documents list to be sent by the customer. The operator can consult a wiki on which documents have to be associated to that kind of customer. Once the list is defined, the customer is notified by RSS that he can start to send documents;

• “Appointment planning”: the customer indicates his preferred date for the appointment by consulting the calendarof his agency’s sellers. Sellers receive an RSS notification and the first confirming the appointment will take in charge the customer. The customer receives confirmation about the appointment by RSS and e-mail. The customer and the Call Center operator can also communicate about the appointment by blog or messenger;

• “Documents upload”: the customer and/or the seller uploads the required documents. They can talk about documents by blog or messenger;

• “Outcome registration”: that is the output task. The seller registers the final resolution about starting or not a C.Q.S. instance. The seller can consult a wiki about the registration task, and the customer is notified about the outcome by RSS and e-mail.

Application of the new Methodology: Collaborative Business Processes

Differently, from the “First contact” sub-process, the “Application form” is strictly procedural and is unsuitable to be conceived as a collaborative workspace. For this reason, we are modeled “Application form” as a collaborative business process, following the guidelines described in paragraph two:

     1. Analysis and Classification of Activities

All possible collaboration dynamics inside every sub-process task are elicited. Following the proposed task classification, we found that:

• the tasks “Information request” and “Providing information” can be classified as collaborative because they imply a cooperation between the involved stakeholders (Seller and Customer); for this reason, a collaborative environment could help them to reach the goal of collecting the complete set of information that are necessary to fill out the application form;

• The task “Verification of information completeness” implies no interactions between the different stakeholders’ classes so it can’t be classified as collaborative. However, we classified such activity as indirectly collaborative because some kind of reference knowledge on the specific activity could be a helpful support for the agency officer in performing his task;

• All the other tasks are no-collaborative because they are elementary operations, which don’t need any kind of cooperation.

The following figure illustrates the first lines of the table resulting from this step of analysis:

     2. Revising the AS-IS Design

In this step, we modified the AS-IS BPMN model by means of the “message flow” and “task loop” stereotypes used to represent the collaborative tasks previously identified (“Information request”, “Providing information”)

Fig 6. Application form BPMN diagram – step 2

    3. Modeling the Collaborative Business Process. Here, we further modified the BPMN model in order to represent all the collaborative aspects already described:

•    we used the “collaborative lane” new stereotype in order to contain the identified collaborative tasks. The collaborative lane is labeled with the name of all stakeholders involved in the execution of the collaborative tasks, in our case “Seller/Customer”. The lane contains the task “Information integration” that summarizes the previous “Information request” and “Providing information” collaborative tasks.

•    we represented the indirectly collaborative task “Verification of information completeness” by means of the script task stereotype.

The following figure shows the new diagram obtained:

Fig 7. Application form BPMN Diagram – step 3

   4. Customization of the Collaborative Activities. At this step, we selected the collaborative tool to be applied to the collaborative and indirectly collaborative identified tasks:

• in the case of the collaborative task “Information integration”, we chose the blog collaborative tool because the collaboration between the stakeholders would be usually asynchronous. The blog has process instance scope because it refers to the C.Q.S. process and has a different instance for each customer loan’s request;

• for the “Verification of information completeness” indirectly collaborative task, we chose the wiki collaborative tool as the source of knowledge. The wiki has process scope because there is only one wiki instance for the C.Q.S. process.

The following figure illustrates the table resulting from this step of customization

After having selected the collaborative tools, we represented them on the BPMN diagram, by means of a specific syntax suggested by the methodology: each task using a collaborative tool is labeled with the first capital letter of the object (i.e. “W” stands for wiki, “B” stands for blog,…). The following figure shows the final BPMN collaborative process model:

Fig 8. Application form BPMN Diagram – step 4

   5. Direction for use of collaborative mode

In the last step, for each collaborative tool we specified:

• the roles and the permissions of the different stakeholders, on the base of the roles defined into the collaborative tool dictionary provided by the methodology as a guideline, ;

• an identification number (id) to be associated to each collaborative tool in order to univocally identify it within the set of collaboration tools in use by the organization owning the process.

We represented all these details in the following table:

Finally, we represented the information contained in the table by means of a diagram showing the interaction between the stakeholders and each collaborative tool. In the following figure, there is the graphical representation for the blog collaborative tool:

Fig 9. Blog Roles Diagram

 
The aim pursued by the financial institute in process reengineering is to obtain a quality improvement by introducing collaboration dynamics, that’s particularly significant for processes like C.Q.S., characterized by a wide variety of stakeholders’ classes.

The quality improvement will be perceived by all stakeholders: the new approach will provide the customer and the financial institute with a faster way to meet each other and exchange information; at the same time, the financial institute will have a way of acquiring and sharing knowledge capitalizing it for a continuous process improvement.

All these aspects will result in a reduction of process execution time and a proactive involvement of financial institute officers in the organizational knowledge creation.

The Framework Architecture

According to the methodological guidelines, we defined a framework which architecture is represented in the following picture:

Fig 10. The Framework Architecture

The core element of our architecture is the Hub Collaboration Engine, which aims to associate at run-time collaboration tools to each process step or workspace task, as defined in the modelling phase.

The Collaborative Client component, within each business application, sends information about the current process step (or workspace task) and instance to the Hub Collaboration Engine which asks the Business Application Management component:

• what are collaborative tools associated to that step;

• the visibility (i.e. “scope”) and access control (roles and stakeholders involved) rules to be applied to each collaborative tool;

• the set of possible content recipients for each stakeholder.

Hub Collaboration Engine sends all information gathered to the Collaborative Layout Renderer component which will refresh the process page by rendering the Collaborative Tools to be associated to the step. The Collaboration Tools Repository component contains the implementation of all thesauruses’ collaboration tools.

In order to contextualize collaborative user generated contents, the architecture contains also components for indexing and searching functionalities based on domain taxonomies:

• the Taxonomy Management component contains taxonomies associated to each process, so Hub Collaboration Engine can extract tags  to be applied to collaboration user generated contents;

• Collaborative Tag Management component gives direction for automatic and manual content tagging;

Indexer/Searcher component is the collaborative user generated contents indexer and searcher engine and is based on taxonomies associated to each process.

Conclusions and Future Works

Many companies had introduced in a not controlled way the collaborative tools inside their operative procedure.They aimed to provide smart tools for the employees in order to improve their efficiency and thus more competitive processes.

In the past years, this kind of approach has shown many limits such as lack of governance, poor collaboration between the employees; in fact, more efficiency does not mean more tools and collaborative process does not mean blog, chat and social networking.

Now, the market and the company need a more structured approach which is able to evolve the traditional enterprise (based on the concept of workflow) to a more modern company able to manage not only information but knowledge.

For this reason, the business process must be evolved in order to model the collaboration aspect. The proposed approach is a set of steps that aims to help the designer to consider first the collaboration inside the single task, then the collaboration in the entire process, and at last, chooses the collaborative tools more suitable with the designed collaboration.

This kind of approach has the benefit to be incremental leading step-by-step the designer to a new BPMN (extended with new concepts) without misreading the AS-IS version. The explanation of the methodology is made through the application to a real case study of the finance sector.

The results seem good and the finance institution is applying now in the development of the applications that implement the new collaborative process.

References

Erol, S., Granitzer, M., Happ, S., Jantunen, S., Jennings, B., Johannesson, P. Koschmider, A. Nurcan S., Rossi, D.& Schmidt, R. (2010). “Combining BPM Social Software: Contradiction or Chance?,”  Journal of Software Maintenance and Evolution: research and practice, Wilely Interscience on-line.
Publisher

Hawryszkiewycz, I.T. (2009). ‘Designing Collaborative Infrastructures for Business Applications,’ Proceedings of the IADIS International Conference WWW/INTERNET09, ISBN: 978-972-8924-93-5, Rome, Italy, 93-97.

McAfee, A. P. (2006). “Enterprise 2.0: The Dawn of Emergent Collaboration,” MITSloan management review, 47(3), 21-28
Publisher – Google Scholar – British Library Direct

Nurcan, S.  & Schmidt, R. (2009). “BPM and Social Software,” Business Process Management Workshops, 649–658.
Publisher – Google Scholar

OMG (2009). ‘Business Process Modeling Notation,’ V.2.0. Retrieved March 1, 2010, from http://www.bpmn.org
Google Scholar

Paiano, R. & Pandurino, A. (2010). ‘A Structured Approach to the Introduction of Enterprise 2.0,’ Proceedings of IADIS International Conference WWW/INTERNET 2010, ISBN:978-972-8939-25-0, Timisoara, Romania, 313-318.