During business trips company employees being in a dynamic, unfamiliar environment are exposed to various threats (both to well-being, and to effectiveness in performing their business responsibilities), therefore, business trip risk management is one of the integral parts of the overall business process resilience. This paper proposes an approach of leveraging a novel humancomputer cloud concept to perform some of typical tasks required to implement organization's travel risk management policy. In particular, it is proposed to use human-based application deployed in human-computer cloud (1) to assist in pre-trip investigation required to assess travel risks and develop trip instructions, (2) to support travelling employees in case of unexpected incidents.
Business process resilience is generally defined as the ability to adjust easily to
change (caused by economic factors, natural disasters, government decisions etc.) [
Increasing importance of this problem is supported by various analytical reports.
E.g., according to Ipsos MORI Global Business Resilience Trends Watch 2018, 63%
of business decision-makers perceive travel risks to have increased in 2017. At the
same time, only 9% of organizations updated their sustainability program to include
travel risk policy [
This paper proposes an approach to address some of the business resilience
problems (specifically, business trip resilience) that is based on human-computer cloud
(HCC) concept. The key of reaching resilience is identification of influences and
quickly adapting to them. In the technological sense, one important perspective of
changes is availability of computing infrastructure and variation of computing
resource utilization (that can be caused by different external factors). These changes can
be addressed with a help of conventional cloud computing technology, which
provides means to elastically manage the computing capacity consumed by business
processes [
In the previous work, the authors developed the original architecture of
humancomputer cloud [
Crowdsourcing is usually defined as a way of outsourcing, where tasks
traditionally performed by company’s employees or other companies are forwarded to members
of an undefined large group of people (called “crowd”) by means of internet (e.g.,
[810]). In this sense, HCC provides technological means for crowdsourcing. An
important question regarding to using crowd for solving some tasks is “what are the
factors that influence the decision of whether it is possible to use crowdsourcing and
crowd computing to perform some part(s) of the company’s business process?”
Though business process crowdsourcing (originally introduced by Vecchia and
Cisternino [
Taking into account limitations of crowdsourcing applicability (e.g., requirement of some specific expertise, sensitive data processing) and factors influencing the possibility of crowdsourcing, first, a set of particular tasks of travel risk management that were implemented as human-based applications was mostly limited to informationcollection tasks, second, the private-public human-computer cloud approach was proposed.
The proposed approach touches Risk monitoring (RMON) and Risk assessment
(RA) process areas of Travel Risk Management Maturity Model (TRM3) [
The rest of the paper is structured as follows. Section 2 contains some basic information about human-computer cloud concept and an approach to implementing it. Section 3 introduces the hybrid human-computer cloud environment that allows to partially sidestep pitfalls of crowdsourcing applicability by creating private cloud (connected with a public one). Section 4 discusses some of the trip management tasks that can be implemented on top of the cloud. 2
This section briefly describes HCC concept in its historical evolution and the
particular approach to implementation of this concept taken by the authors. While this
section should be enough to get most ideas behind the proposed platform, more details
can be found in previous publications [
Although, typical capabilities provided by cloud are storage, processing,
networking and software, cloud computing recently is perceived as a more general concept
resulting to various attempts of applying elastic on-demand resource management
principles (sometimes called XaaS or *aaS). This includes several developments
where human information processing abilities were treated and provided in a
cloudlike way. One example of this kind of systems was described in [
While in our work we adopt the ideas of the cited publications, namely, using cloud-inspired resource management approach for human-based applications, we extend it by two distinguishing features. That are ontologies and digital contracts. Ontological mechanisms (ability to precisely define semantics and use inference to find related terms) are used to find and allocate human resources required by software services. While digital contracts are used to achieve predictability required by cloud users (application developers). These digital contracts specify terms on which a conm r o f t laP Information Storage &
Exchange Services
Processing Services Human Workflow Services s e i g o l o t n O
tributor agrees to provide his/her competencies to the cloud application developer, rewarding and possible penalties. Cloud environment uses these contracts both to allocate service’s task and to inform users about possible capacity. 2.1
Although NIST recommendation document [
Cloud consumers, who use the applications and services deployed in the cloud environment (and provided by Cloud providers). Further, this category of actors can be divided into End users and Service developers. This division is mostly determined by the kind (and a level) of services a consumer deals with. For example, when using the cloud for business trip resilience, possible end users are traveling employees or business trip managers, because they use cloud services (mostly, on the SaaS layer) to solve domain specific tasks. Service developers use the services of the platform layer to create application services for end users.
Contributors, i.e., citizens, who are available to serve as human resources in a HCC environment.
Cloud providers, individuals or organization who own and maintain the required hardware and software infrastructure provided to Cloud Consumers. This includes, for example, system administrators. 2.2
All the three models of cloud computing (IaaS, PaaS, SaaS) can be adapted to include human resources (Fig. 1).
Infrastructure layer: Infrastructure layer unifies different types of capabilities: traditional computing and storage capabilities, sensing capabilities and human expertise capabilities. Contributors can join HCC and define the resources they can provide, time and load restrictions, a type of tasks they may participate. In the infrastructure layer resources (including human resources, or contributors) are not locked to some particular domain. Instead, they describe their competencies and possible kinds of activities using some of the available ontologies to leverage the resource identification phase that happens when some application that require human participation is deployed in the cloud environment. Ontology-based resource discovery service performs ontology search involving ontology matching techniques as necessary. Infrastructure layer management monitors contributor connections and disconnections, collects information about effectiveness of each contributor (separately for each skill a contributor is allocated by) and uses it in further allocation requests.
Platform layer: This layer consists of a set of multi-purpose utility services that can be leveraged for building applications relying on human expertise, and development tools, that are used to deploy and run human-in-the-loop services in the cloud environment.
Development tools of the platform layer allow to deploy services in cloud environment and to monitor them. Each service being deployed includes an ontologybased descriptor, specifying: - building/configuration instructions; - hardware and software requirements of the service (what platform services it relies on, e.g., database service, human workflow service, etc.);
- human resource requirements (if any), specifying what human skills and competencies this service need to function. These requirements are also resolved during the service deployment, but as (1) resolving these requirements employs ontology matching which may result in some tradeoffs, (2) human resources are much more limited than hardware/software, the status and details of the requirements resolution are available to the developer and can be browsed via the management console; - description of the service functions and entry points to be published in the application domain service repository and used by the ad hoc dynamic workflow service.
Typical interoperability scenario that is initiated in the platform layer during deployment is the following: the human resources connected to the cloud environment describe their capabilities using some problem-specific dictionaries. Each application/service that is deployed in this cloud environment contains a description of its requirements (including the requirements to the resources), which is expressed in terms of the most appropriate ontology selected (or even designed) by the application developers. It is very unlikely that human resources have used this exact ontology to describe their capabilities when connecting to the system. However, the advantage in using ontologies here is that due to the formal semantics inherent to them different ontologies can be matched. Hence, in the process of service deployment, human resources that are potentially able to fulfill the human requirements of the service are identified (despite the fact that they are not described initially in terms of the application ontology). Later, during the functioning of the service, the participants’ description can evolve, because his/her performance in the capabilities required by the service (and expressed in terms of service’s ontology) is recorded and processed. For each further service that is deployed in this environment, the process of aligning requirements with the capabilities of human resources becomes easier, as human resources definition becomes more and more detailed.
Software layer: This layer consists of a suite of (potentially human-based)
services and applications designed for a particular problem area. E.g., in the area of
tourism there are various services like itinerary planning, feedback collection and many
others [
Conceptual schema of the proposed approach is presented in Fig. 2. The proposed cloud-based decision support is aimed at the decision points of workflows, which are formalised and ready for implementation representations of business processes.
Due to privacy issues and possible presence of sensitive information, usage of external human resources (i.e., crowdsourcing as one of the cloud resources) may be limited. However, it doesn’t apply to the internal human resources of the organization. Therefore, decision support cloud follows the so-called hybrid cloud model, were all the resources are divided between private (on-premise) cloud and public (external) cloud. In case of traditional computing resources, directly accessible private cloud reduces time and latency compared to access to public resources, besides, private cloud may cover average workload, retaining the ability to use public resources, when it is needed. Hybrid HCC inherits all those features, but has one more. Private cloud contains a pool of unique human resources that can be used with much less restrictions then those from the outside. Uniqueness of these resources is due to the fact that members of the private cloud are actually employees of the organization with all legal and practical consequences, e.g., they are enforced to obey non-disclosure agreement, and they may be more familiar with the context of each particular task. It puts human resource scheduler of the private cloud very close to the workflow engine (e.g., BPEL- or BPMN-based), but modelling all the human resources (private and public) as cloud resources allows to build a unified scheduler. I.e., a single scheduler ‘faced’ with some request that contains a sensitive data may allocate resources from the private cloud, but ‘faced’ with some request that doesn’t contain sensitive data may automatically allocate resources from public cloud, automatically resorting to ‘crowdsourcing’. This is only possible if resources of the both clouds are described in the same form and provide aligned APIs.
Services and resources (including crowd)
process
Private humancomputer cloud Decision support software Human & computer resources The decision support assumes delegation of tasks to a cloud consisting of both (a) IT tools, which can provide information for decision support (decision support systems), provide recommendations (recommendation systems) or even do some decision making (expert systems); and (b) company (and outer) experts, who can either assist in decision making or make the required decisions. Therefore, all the three cloud layers are present in the architecture. Infrastructure-as-a-Service (IaaS) layer is formed by computing, storage and human resources, that can be used in the process of decision support. Platform-as-a-Service (PaaS) layer is not explicitly depicted in the Fig. 1, but it is formed by the intermediary services allowing to build end-user applications. Finally, the Software-as-a-Service (SaaS) layer that is represented by different forms of decision support software. 4
This section describes the way human-computer cloud capabilities are utilized for business trip risk management. It analyses some recommended practices for managing business trip risks and shows how these practices can be implemented on the basis of hybrid human-computer cloud. 4.1
GBTA Europe Risk Committee has recently identified five pillars of travel risk
management [
Besides, in case something unexpected happens while an employee is on the trip, he/she might need information support accounting for the new situation. And that may also be simpler for persons with local knowledge. Therefore, there are basically two scenarios human-based information collection applications are used in business trip management: pre-trip risk assessment and on-trip support.
Basic workflow of risk information collection is performed by a travel risk manager role who is in charge of what kind of information has to be collected to prepare people to business trips and make them safe. In some sense, this role is responsible for resilience in business process of business trip organization. However, in a company that has an intense (or significantly varying) business trip schedule it might be hard to collect all the needed information. On the other hand, this particular information can be collected by local people/agencies. So, the travel risk manager submits the required information to the travel information collection application, these requests are directed to contributors with local expertise who provide the required information.
Collect longterm local information Collect shortterm local information Store information for future uses
Web, State foreign department recom
mendations etc.
Real-time queries to people with local
expertise
Travel risk knowledge base Simplified workflow of pre-trip risk assessment investigation is shown in Fig. 3. When assessing risks of business trip to some new location, travel risk manager collects both long-term information about the destination, as well as short-term information. This information is stored into Travel risk knowledge base so that (1) in the subsequent travels to the same destination pre-trip risk evaluation might reuse large portions of it (depending on the time passed from the collection and classification of the information), (2) this knowledge base is used to send information emails to the employees before the trip and even in the trip. Potentially, in case of working employee travel tracking system, the knowledge base may be also used for online alerts and on-trip information support, however, this is out of scope of this paper.
This workflow sidesteps the specific content of the information that need to be collected. In fact, the particular list of the information items (or, trip preparation checklist) as well as classification into “long-term” and “short-term” information items is a part of travel risk assessment methodology developed in the particular organization as a result of another process.
This scenario is activated while an employee is on the trip. However, there are two possible initiators of it. The first one is travel risk manager who monitors general news stream about locations where company employees are currently on the business trip and decides if the situation is changed severely enough that general instructions about the destination might have become obsolete. In this case, travel risk manager initiates a new information collection cycle resulting in the information emails to the employees about new safety and security instruction in the changed situation.
However, in some cases a travelling employee might face problems that while are not objectively so significant to be reflected in a news stream, nevertheless create serious threat for efficiency. In this case, an employee may directly access to local experts who can provide the required information. 4.2
The simplest way to implement these scenarios with the help of HCC is to implement a set of human-based applications (leveraging the intellectual abilities of contributors working with the cloud) and deploy them in the cloud environment. Development of human-based applications is possible with the toolset provided by the PaaS layer of the platform. Due to current limitations of the platform, there applications can only be web applications exposing RESTful API. Therefore, software part of the travel risk management workspace has to consist of a desktop (or web) application (possibly integrated with other enterprise software) providing user interface and human-based application deployed in the HCC. These two applications communicate over HTTP via RESTful interface (Fig. 4). This figure shows a simplified case, when there is no private cloud part and travel risk manager workplace application directly connects to the public Travel information collection application. In a more elaborate case suitable for bigger organizations able to deploy own computing infrastructure and ready to deploy private cloud, the schema transforms roughly to what is shown in Fig. 2, i.e. travel risk manager workplace connects to the application deployed in the private cloud, and if the application fails to collect needed information among private cloud contributors, the request is passed forward to the public cloud.
Human-based application deployed in the cloud requires a deployment descriptor defining resource requirements of the application and digital contract templates.
During the deployment of this travel risk collection application the ontology concepts used for description will be matched to the resource description profiles and notifications of contribution possibility (called advertisements in the terminology of the platform) will be sent out to respective contributors. Travel risk manager
Enterprise software
RESTful
API Contributors
Human-computer cloud The paper proposes to use elements of crowdsourcing (implemented via a novel concept of human-computer cloud) for information collection activities in the scope of business trip risk management. The approach suggests to route information collection requests issued by organization’s business trip risk manager to local experts whose work for HCC environment is regulated by digital contracts (which allows to reach predictability in resource availability and response time). A hybridization (private/public) of human-computer cloud was proposed that allows to sidestep some of the pitfalls of external execution of inner organization tasks.
The proposed approach goes very well with will Travel Risk Management Maturity Model and may facilitate reaching Level 3 (Proactive) according to this model by an organisation.
Acknowledgements. The research is funded by the Russian Science Foundation (project # 16-11-10253).