Enterprise 2.0: Research Challenges and Opportunities

Abstract

Blending Web 2.0 technologies with enterprise information systems is setting up the stage for a new generation of information systems that will help enterprises open up new communication channels with their stakeholders. Contrary to traditional enterprises with top-down command flow and bottom-up feedback flow, the same flows in Enterprise 2.0 cross all levels and in all directions bringing people together in the development of creative and innovative ideas. The power of Web 2.0 technologies stems from their ability to capture real-world phenomena such as collaboration, competition, and partnership that can be converted into useful and structured information sources from which enterprises can draw information about markets’ trends, consumers’ habits, suppliers’ strategies, etc. This paper discusses the research efforts that our international research group has put into the topic of Enterprise 2.0 (aka Social Enterprise). In particular, our research group advocates that existing practices for managing enterprise information systems need to be re-visited in a way that permits to capture social relations that arise inside and outside the enterprise, to establish guidelines and techniques to assist IT practitioners integrate social relations into their design, development, and maintenance efforts of these information systems, and last but not least to identify and tackle challenges that prevent capturing social relations.

This paper is based on the 1$^{st}$ author’s invited talk at the 10$^{th}$ International Conference on Web Information Systems and Technologies (WEBIST’2014), April 3-5. Barcelona, Spain.

1 Introduction

With the recent boom in Web 2.0 technologies (e.g., JSON and AJAX) and applications (e.g., Facebook¹ and Twitter), there is a major trend in blending social computing with other forms of computing for instance, service computing [1, 2] and mobile computing [3, 4]. In this paper, we look into the blending of Web 2.0 concepts and technologies with enterprise computing that results into the development of Social Business Processes (SBP)s [5, 6]. In particular, SBPs capitalize on Web 2.0 technologies and applications to ensure that the social dimension of the enterprise (aka Enterprise 2.0 [7, 8]) is not overlooked during BP design and enactment. This dimension sheds the light on the informal networks that co-exist perfectly with formal networks where relations like supervision and substitution occur [9]. Different studies have shown the value-added of weaving social computing into enterprise operations in terms of demystifying who does what, profiling customers, and even re-engineering processes [10, 11]. Moreover, many enterprises recognize the need of rethinking their strategies and reevaluating their operating models, as the world is getting more “social” [12].

Despite the growing interest in enterprise 2.0 in general and SBPs in particular, several limitations continue to hinder this interest. For instance, how to equip BP engineers with the necessary methods and techniques that will assist them capture the requirements of SBPs. Enterprises are still unsure about the return-on-investment of Web 2.0 technologies [13]. A recent study by Gartner reveals that “...many large companies are embracing internal social networks, but for the most part they’re not getting much from them” [14]. Over the last 2–3 years, our international research group has put efforts into enterprise 2.0 topic from different perspectives with focus on social design, social coordination, and social monitoring in this paper. Some of these efforts’ results are reported in [6, 15]. Contrary to traditional enterprises with top-down command flow and bottom-up feedback flow, the same flows in Enterprise 2.0 cross all levels and in all directions bringing people together in the development of creative and innovative ideas. In principle, the power of Web 2.0 technologies stems from their ability to capture real-world phenomena such as collaboration, competition, and partnership that can be converted into useful and structured information sources from which enterprises can draw information about markets’ trends, consumers’ habits, suppliers’ strategies, etc.

The remainder of this paper is organized as follows. Section 2 briefly describes a case study to be used for illustration purposes. Section 3 provides an overview of three of our initiatives that look into enterprise 2.0 from the following perspectives: social design, social coordination, and social monitoring of business processes. Finally, we conclude the paper in Sect. 4.

2 Illustrative Case Study

Our case study refers to the electronic-patient-folder system at Anderson Hospital that handles approximately 6000 annual inpatient admissions². We leverage this system to identify first, some business processes’ components (tasks, persons and machines) and second, the execution nature of some tasks. When a patient shows up at the hospital, the necessary documentation is scanned into a system known as ImageNow. Upon completion the scanned documentation is linked to the patient’s MEDITECH record. An advantage of this linkage is that different stakeholders like billing staff, coders, and other authorized people have immediate, electronic access to the necessary information instead of waiting for the paper documentation to arrive. Prior to implementing the new system Anderson Hospital faced different challenges such as paper records limit access to one user at a time and paper and manual processes hamper compliance with some healthcare standards.

3 Challenges and Opportunities

Our international research group has launched several initiatives to tackle the challenges that enterprise 2.0 faces and tap into the opportunities that enterprise 2.0 offers. In the following, we discuss three of these initiatives that look into enterprise 2.0 from the following perspectives: social design, social coordination, and social monitoring of business processes.

3.1 Social-Design Research Initiative

According to Faci et al. [16], the lack of design approaches for modeling SBPs is not helping enterprises capitalize on Web 2.0 applications’ capabilities such as reaching out to more customers, collecting customers’ online posts, and profiling customers. A recent study of 1,160 businesses and IT professionals reveals that “only 22 percent of organizations believed that managers are prepared to incorporate social tools and approaches into their processes. Moreover, two-thirds of respondents said they were not sure they sufficiently understood the impact these technologies would have on their organizations over the next three years” [17].

Our initiative on BP social design sheds the light on the three components of a process as well as the relations that connect these components, i.e., task ($\textsf {t}$), person ($\textsf {p}$), and machine ($\textsf {m}$) [6]. A task is a work unit that constitutes with other tasks a business process and that a person and/or machine execute. Task execution is either manual, automatic, or mixed. Figure 1 illustrates a simple healthcare-driven BP along with some components for instance, $\textsf {t}_1$ : scan documentation, $\textsf {m}_2$ : ImageNow system, and $\textsf {p}_j$ : cashier. To execute tasks and hence complete processes, resources are required (Sect. 3.2).

Fig. 1.

Example of a business process’s components.

In addition to the traditional execution relation that connects persons/machines to tasks, we establish social relations between tasks, between persons, and between machines. The following are examples of social relations [6]:

• Interchange: $\textsf {t}_i$ and $\textsf {t}_j$ engage in an interchange relation when both produce similar output with respect to similar input submitted for processing and their requirements do not overlap (e.g., $\textsf {t}_1$: scan documentation and $\textsf {t}_1^{'}$: enter patient details manually). The non-overlap condition avoids blockage when $\textsf {t}_i$’s requirements (e.g., online data entry) cannot be met due to absence of executors and thus, $\textsf {t}_i$ needs to be interchanged with $\textsf {t}_j$ that has different requirements (e.g., manual data entry).

• Backup: $\textsf {m}_i$ (e.g., scanner in main reception) and $\textsf {m}_j$ (e.g., three-function printer in nurse station) engage in a backup relation when both have similar capacities.

• Delegation: $\textsf {p}_i$ and $\textsf {p}_j$ engage in a delegation relation when both are already engaged in a substitution relation based on their respective capacities and $\textsf {p}_i$ decides to assign a task that she will execute or is now executing to $\textsf {p}_j$ due to unexpected changes in her status, e.g., call-in-sick or risk of overload (e.g., general practitioner transferring patient to emergency physician due to case severity).

Table 2 summarizes the social relations between tasks, between machines, and between persons along with their respective pre-conditions, conditions, and post-conditions. Pre-condition defines the rationale of establishing a social relation between a process’s components. Condition indicates when a network built upon a social relation is used so that solutions to conflicts that prevent a business process completion are addressed (Sect. 3.2). Finally post-condition indicates when to stop using a network.

Table 1. Summary of social relations.

Figure 2 depicts examples of networks related to the case study that are generated at run-time. For example, a network of machines is built to specify the backup relation between $m_1$ (scanner) and $m_2$ (three-function-printer) since both machines have similar capacities. A configuration network of tasks is also constructed to express the interchange relation between $t_1$ (scan-documentation) and $t_2$ (enter-patient-details-manually). Both tasks produce similar output and their requirements do not overlap. Last and not least, a social network of persons is built to describe the peering relation between $p_2$ (cashier) and $p_3$ (financial-manager) since both persons have complementary capacities that are necessary to achieve $t_5$ (prepare- bill). This social network expresses also a substitution relation between $p_3$ (general-practitioner) and $p_4$ (emergency-physician) since both have the same capacity.

Fig. 2.

Screenshot of the BP execution social analysis component. A demo video is available at https://www.youtube.com/watch?v=Py5oGPQot64.

3.2 Social-Coordination Research Initiative

According to Faci et al. [16], agility of today’s enterprises should not be confined to the organizational borders of the enterprise. Other vital aspects of the enterprise need to be taken into account such as re-engineering business processes, revisiting the practices of those executing these processes, and redefining the nature of resources that are made available for these processes at run-time. Since resources (e.g., data, power, and CPU time) do not sometimes last forever and are not unlimited and/or shareable, tasks and persons/machines need to coordinate the consumption and use of these resources so that conflicts are avoided and addressed, if they occur. Besides regular conflicts in terms of data and policy incompatibilities between enterprise systems, additional conflicts exist due to time constraints and/or simultaneous access to limited and/or non-shareable resources. Coordination is the best way to address these conflicts.

Our initiative on BP social coordination includes four steps [15]: categorize resources that tasks require for their execution, define how tasks/machines/persons of a BP bind to resources in order to achieve this execution, categorize conflicts on resources that arise between tasks, between machines, and between persons, and finally analyze the appropriateness of certain networks of tasks/persons/machines for addressing these conflicts. These networks are established during BP social design as per Sect. 3.1.

We categorize resources into (i) logical, i.e., their use/consumption does not lead into a decrease in their reliability/availability level and (ii) physical, i.e., their use/con-sumption does lead into a decrease in their reliability/availability level. This decrease requires resource replacement³/replenishment at a certain stage. We also define a set of properties that permit to describe a resource. These properties are limited (l - when a resource use/consumption is measured or a resource ceases to exist either in compliance with its use/consumption cycle - to be introduced later - or because of constraints like temporal), limited but renewable (lr - when a resource use/consumption either hits a certain threshold or is subject to constraints like temporal; in either case renewal is possible), and non-shareable (ns - when a resource simultaneous use/consumption has to be scheduled). Unless stated a resource is by default unlimited (ul) and/or shareable (s). Table 2 suggests some examples of resources per category and property. To identify these examples we rely on the business process of Fig. 1.

Table 2. Resource categories and examples.

Figure 3 shows a state transition diagram of a resource. The diagram is developed independently of whether the resource is logical or physical, takes into account the properties of Table 1, and permits to establish a resource’s consumption cycle (cc) per property. On the one hand, the states ($s_i$) of a resource include not made available (neither created nor produced yet), made available (either created or produced), not consumed (waiting to be bound by a task), locked (reserved for a task in preparation for consumption), unlocked (released by a task after consumption), consumed (bound by a task for ongoing performance), withdrawn (ceased to exit after unbounding all tasks if necessary), and done (updated as per relevant property if necessary, and unbound by task). It should be noted that other states in a consumption cycle’s diagram can be adopted if different properties are used without deviating from the aforementioned purpose of using this diagram. On the other hand, the transitions ($trans_j$) connecting a resource’s states together include start, waiting to be bound, consumption approval, consumption update, lock, release, consumption rejection, consumption completion, renewable approval, and no-longer useful. Upon a transition satisfaction, a resource takes on a new state.

Fig. 3.

State transition diagram of a resource.

We list below some sequences of states (s) and transitions (trans) that represent a resource’s consumption cycle per property denoted as $r(cc_{\textsf {property}})$ = $s_{i}\buildrel {trans_i} \over \longrightarrow s_{i+1}\buildrel {trans_{i+1}} \over \longrightarrow s_{i+2}\ldots s_{j-1}\buildrel {trans_{j-1}} \over \longrightarrow s_{j}$ (subscripts in state and transition names are given for notational purposes, only).

• $r(cc_{\textsf {ul}})$: not made available $\buildrel {start} \over \longrightarrow$ made available $\buildrel {waiting~to~be~bound} \over \longrightarrow$ not consumed $\buildrel {consumption~approval} \over \longrightarrow$ consumed $\buildrel {no-longer~useful} \over \longrightarrow$ withdrawn. The resource (e.g., patient medical record) remains available for additional consumption until the transition from consumed to withdrawn is satisfied (e.g., patient discharge).

• $r(cc_{\textsf {l}_{1}})$: not made available $\buildrel {start} \over \longrightarrow$ made available $\buildrel {waiting~to~be~bound} \over \longrightarrow$ not consumed $\buildrel {consumption~approval} \over \longrightarrow$ consumed $\buildrel {consumption~update} \over \longrightarrow$ done $\buildrel {consumption~completion} \over \longrightarrow$ withdrawn. The transition from done to withdrawn then end-of-state shields a resource (e.g., patient list with contagious diseases) from any new or additional tentative of consumption by tasks (e.g., submit patient list to healthcare authorities upon disease detection) after completing a consumption cycle. In done state a resource’s parameters (e.g., accuracy level such as patient list obsolete) are updated and the resource is detached (or unbound) from tasks.

• $r(cc_{\textsf {lr}})$: not made available $\buildrel {start} \over \longrightarrow$ made available $\buildrel {waiting~to~be~bound} \over \longrightarrow$ not consumed $\buildrel {consumption~approval} \over \longrightarrow$ consumed $\buildrel {consumption~update} \over \longrightarrow$ done $\buildrel {renewable~approval} \over \longrightarrow$ made available. The transition from done to made available permits to regenerate a resource (e.g., file of interns) for another round of consumption (e.g., internship extension).

Based on resource categories and their properties and how tasks/persons/machines bind to resources, we examine conflicts over resources between tasks, only for illustration purposes. The following notation is adopted: $t_i/m_i/p_i \rightarrow r_i$ means that a resource is made available for a task/machine/person; $r_{i,j}$ means that a resource produced by a certain task (resp. machine/person) is transferred to another similar (resp. similar/different) peer for the needs of consumption (resp. use); and, $r_{i,\{j,k,\cdots \}}$ generalizes $r_{i,j}$ but this time the resource is shared between peer$_{\{j,k,\cdots \}}$. $\mathcal {T}$-Conflict$_1$ is an example of conflicts between tasks with emphasis on resource consumption and not data (inputs and outputs) and policy incompatibilities between these tasks. $\mathcal {T}$-Conflict$_1$ arises when (i) a prerequisite relation between $\textsf {t}_i$ and $\textsf {t}_j$ exists, (ii) consume $(\textsf {t}_i,\textsf {r}_i)$ $\rightarrow$ produce($\textsf {t}_i,\textsf {r}_{i,j})$, and (iii) $\textsf {t}_j$ needs $\textsf {r}_{i,j}$ (i.e., $\textsf {t}_j \nrightarrow \textsf {r}_j$, no $\textsf {r}_j$ is made available for $\textsf {t}_j$). Potential conflicts on $\textsf {r}_{i,j}$ (and eventually $\textsf {r}_{\{i,k,\cdots \},j}$ and $\textsf {r}_{i,\{j,k,\cdots \}}$) because of the limited property of $\textsf {r}_{i,j}$, include:

• l: two cases result out of the prerequisite relation between $\textsf {t}_{\{k,\cdots \}}$ (e.g., complete necessary paperwork) and $\textsf {t}_j$ (e.g., direct patient to appropriate department) on top of the same relation between $\textsf {t}_{i}$ (e.g., check patient vitals) and $\textsf {t}_j$:

  • (a) $\textsf {r}_{i,j}$ (e.g., report on vital levels) ceases to exist (e.g., blood sample no longer valid) before the execution of $\textsf {t}_j$ begins; $\textsf {t}_j$ waits for $\textsf {t}_{\{k,\cdots \}}$ to produce $\textsf {r}_{\{k,\cdots \},j}$ (e.g., insurance provider approval); (at least one) $\textsf {t}_{\{k,\cdots \}}$ either is still under execution (e.g., due to delay in receiving approval from insurance provider) or failed.

  • (b) Only one consumption cycle of $\textsf {r}_{i,j}$ is permitted (per type of property) but it turns out that several consumption cycles of $\textsf {r}_{i,j}$ are required to complete the execution of $\textsf {t}_j$ and finish the consumption of $\textsf {r}_{\{k,\cdots \},j}$ that $\textsf {t}_{\{k,\cdots \}}$ produce.

After identifying the different task conflicts on resources, we suggest solutions for these conflicts based on the networks that are established in Sect. 3.1. These solutions consider the fact that tasks are associated with transactional properties (e.g., pivot, retriable, and compensatable) that limit their re-execution in the case of failure [18]. The following examines briefly how the interchange and coupling networks of tasks are used to address $\mathcal {T}$-Conflict$_{1}$-Case a.

• (a) $\textsf {r}_{i,j}$ ceases to exist before the execution of $\textsf {t}_j$ begins; $\textsf {t}_j$ waits for $\textsf {t}_{\{k,\cdots \}}$ to produce $\textsf {r}_{\{k,\cdots \},j}$; at least one $\textsf {t}_k$ either is still under execution or failed. Current statuses of tasks and resources are: state($\textsf {t}_i$): done; state($\textsf {r}_{i,j}$): withdrawn; state($\textsf {t}_j$): not-activated; and state($\textsf {t}_k$): either activated (still under execution) or failed with focus on the latter state below. Because $\textsf {t}_i$ now takes on done state, pivot (canceling $\textsf {t}_i$) and retriable (re-executing $\textsf {t}_i$) transactional properties are excluded from the analysis of developing solutions to address resource conflicts. This analysis is given in Table 3. The objective is to re-produce $\textsf {r}_{i,j}$ (or produce $\textsf {r}_{i^{'},j}$ with $\textsf {t}_{i^{'}}$ being obtained through the interchange network of $\textsf {t}_i$). Because of $\textsf {t}_k$ failure, $\textsf {r}_{k^{'},j}$ is produced using $\textsf {t}_{k^{'}}$ that is obtained through the interchange network of $\textsf {t}_{k}$.

Table 3. Possible coordination actions for $\mathcal {T}$-Conflict$_1$/limited property/case$>$a.

Fig. 4.

System’s screenshots.

Figure 4 illustrates a screenshot for an under-development proof-of-concept for a rule-based engine that focuss on implementing the strategies reported in Table 3.

3.3 Social-Monitoring Research Initiative

According to Faci et al. [16], monitoring seems to be the commonly-used technique for tracking the execution progress of BPs. Besides providing a real-time and end-to-end view of this progress, monitoring should also offer an organizational and social view over this progress in terms of who executes what, who delegates to whom, and who sends what, to whom, and when. Obstacles that hinder BP successful completion are multiple (e.g., lack of necessary machines that can execute tasks) and hence, will impact the enterprise effectiveness (e.g., delay in delivery) and efficiency (e.g., costly machine re-allocation). The difficulty of measuring intangible and ad-hoc exchanges between people when executing tasks represents a major barrier to social interaction pattern recognition like collaboration and delegation, as well as the role of these patterns in BP improvement. The way these exchanges should happen can be part of a social monitoring framework in which specialized flows connecting these messages are developed to detect anomalies.

Our initiative on BP social monitoring aims of ensuring the successful completion of BPs despite obstacles that could arise and hence, delay this completion. Absence of necessary machines to execute tasks is an example of obstacle. We develop specialized flows known as control, communication, and navigation and enact the development of these flows in conjunction with the completion of a BP. The control flow connects tasks together with respect to the BP’s business logic. The communication flow connects the BP’s executors (machines and/or persons) together when they execute tasks. Finally, the navigation flow connects networks of tasks, networks of machines, and networks of persons together when the BP completion runs into difficulties. These networks are established in the BP social design (Sect. 3.1). We recall that BP completion and hence, task execution requires resources that are sometimes limited, not shareable, and/or not renewable (Sect. 3.2).

BP social monitoring looks into the exchanges of messages that occur between tasks, between executors (persons/machines), and between networks during task execution and conflict resolution. These exchanges lead into developing flows that help identify who supports whom, who sent what, to whom, and when. Figure 5 illustrates the architecture of our flow-based approach for BP social monitoring. Three levels along with their respective flows constitute this architecture. The process level is linked to the control flow, the execution level is linked to the communication flow, and the network level is linked to the navigation flow.

In the following, we examine the interactions between the social, configuration, and/or support networks during a control-flow execution. These interactions establish navigation flows as per the nature of scenario that shapes the progress of this execution. We identify two scenarios: task replacement(explained hereafter) and task delay and decompose the messages supporting network interactions into vertical (v, between the control flow and networks) and horizontal (h, between networks). We associate each network with an authority component ($\textsf {N}_{auth}$, [19]).

Fig. 5.

Cross-flow interactions for BP social monitoring.

Assigning tasks (e.g., scan documentation and enter patient details manually) to potential executors (persons and/or machines) might turn out unsuccessful when the capacities of these executors do not satisfy the requirements of these tasks (Sect. 3.1). Using specific networks, an option consists of replacing tasks that cannot be executed with similar ones and then, looking for executors who have the capacities of satisfying the requirements of the replacement tasks. For illustration purposes, let us assume a control flow that consists of $\textsf {t}_1$, $\textsf {t}_2$, and $\textsf {t}_{i, i\ne 3}$ and that $\textsf {t}_1$’s requirements are not satisfied.

First $\textsf {t}_1$ needs to be replaced with another similar task using the interchange network. The control flow sends this network’s authority ($\textsf {N}_{auth(interchange)}$) a v-message as shown below asking to find a replacement for $\textsf {t}_1$. $\textsf {t}_1$ now acts as an entry node in the interchange network:

After screening the edges that connect $\textsf {t}_1$ to other tasks in the interchange network, $\textsf {t}_{3}$ is selected using the highest weight among all these edges as a selection criterion, for example. Prior to confirming $\textsf {t}_{3}$ as a replacement for $\textsf {t}_{1}$ the $\textsf {N}_{auth(interchange)}$ sends the $\textsf {N}_{auth(coupling)}$ a h-message asking to check for the coupling level between $\textsf {t}_{3}$ and those tasks, i.e., $\textsf {t}_{2}$, that are dependent on $\textsf {t}_{1}$ in the control flow. This message sending is shown below:

Upon receipt of the coupling level from the $\textsf {N}_{auth(interchange)}$ through the $\textsf {N}_{auth(coupling)}$ using the h- and v-messages shown below, the control flow compares this level to a threshold that the BP engineer has set up earlier. Assuming the comparison is valid, $\textsf {t}_{3}$ is now confirmed as a replacement for $\textsf {t}_{1}$ in the control flow with $\textsf {t}_{3}$ being connected to $\textsf {t}_{2}$. Otherwise the search for another task continues.

After updating the control flow, the next step is to identify executors for $\textsf {t}_3$. Assuming a successful match between $\textsf {t}_{3}$’s requirements and some executors’ capacities two exclusive cases arise, which means more messages need to be exchanged. For illustration purposes we assume that executors correspond to persons ($\textsf {p}_3$ for $\textsf {t}_3$).

• 1. Substitution: if there is a concern over $\textsf {pe}_3$’s availability level, the control flow sends the substitution network’s authority ($\textsf {N}_{auth(substitution)}$) a v-message asking to find a substitute for $\textsf {p}_{3}$ with respect to a certain availability threshold ($\textsf {T}_{rel}$). This message along with its response are shown below with $\textsf {p}_{3}^{'}$ being the new executor for $\textsf {t}_3$.

  

• 2. Delegation: if $\textsf {p}_3$ turns out unavailable unexpectedly or will become overloaded by receiving $\textsf {t}_3$ for execution, the $\textsf {N}_{auth(substitution)}$ sends the delegation network’s authority ($\textsf {N}_{auth(delegation)}$) a h-message asking for identifying a delegate, e.g., $\textsf {p}_{3}^{'}$, who could execute the task.

The aforementioned horizontal messages constitute a navigation flow in which states and transitions correspond to nodes in networks and messages between nodes, respectively. Vertical messages trigger the establishment of navigation flows (Fig. 6).

Fig. 6.

Partial navigation flow for an example of business process.

4 Conclusion

In this paper we discussed the blend of Web 2.0 concepts and technologies with enterprise computing. This blend results into the development of Social Business Processes (SBP)s. A SBP exposes the social relations that exist between tasks, between machines, and last but not least between persons. These relations led into developing specialized networks that are used to solve conflicts over resources as well as monitoring the enterprise performance. Although we acknowledges that tasks and machines cannot “socialize” (in the strict sense) like persons do in real life, putting tasks together and machines together suggests a lot of similarities with how persons behave in their daily life. Supporting our claims that tasks and machines can to a certain extent socialize, Tan et al. state that “... Currently, most social networks connect people or groups who expose similar interests or features. In the near future, we expect that such networks will connect other entities, such as software components, Web-based services, data resources, and workflows. More importantly, the interactions among people and nonhuman artifacts have significantly enhanced data scientists’ productivity” [20].