=Paper=
{{Paper
|id=Vol-3389/POCBR90
|storemode=property
|title=FlexiTeam: Flexible Team and Work Organization using Process-Oriented Case-Based Reasoning
|pdfUrl=https://ceur-ws.org/Vol-3389/ICCBR_2022_Workshop_paper_90.pdf
|volume=Vol-3389
|authors=Ditty Mathew,Ralph Bergmann,Benjamin Weyers,Thomas Ellwart,Dominique Bohrmann,Ericson Hölzchen
|dblpUrl=https://dblp.org/rec/conf/iccbr/MathewBWEBH22
}}
==FlexiTeam: Flexible Team and Work Organization using Process-Oriented Case-Based Reasoning==
https://ceur-ws.org/Vol-3389/ICCBR_2022_Workshop_paper_90.pdf
FlexiTeam: Flexible Team and Work Organization
using Process-Oriented Case-Based Reasoning
Ditty Mathew1,* , Ralph Bergmann1,2 , Benjamin Weyers1 , Thomas Ellwart1 ,
Dominique Bohrmann1 and Ericson Hölzchen1
1
University of Trier, Germany
2
German Research Center for Artificial Intelligence (DFKI), Germany
Abstract
During crises such as COVID-19, there is a need to adapt existing work processes and teams to the
changing environment in a very flexible and dynamic way in many business and healthcare organizations.
In this paper, we conceptualize the advances required for Process-Oriented Case-Based Reasoning to
flexibly and dynamically organize human resources in a team and work processes. The novel contributions
of this paper include an extended case representation to represent resources, profiles, and key performance
indicators (KPIs) of processes, a query definition which covers the “context”, and an overall process to
flexibly and dynamically organize work processes and human resources. We evaluate the FlexiTeam
process using a cooking recipe casebase and analyze the quality of the retrieval using a quality measure.
We also derive the research questions that need to be addressed to fully explore this approach and the
specific difficulties involved in solving this problem.
Keywords
Process-Oriented Case-Based Reasoning, Process Management, Workflow Management
1. Introduction
In the current COVID-19 pandemic, healthcare organizations, but also many businesses, are
having to adapt their existing work processes1 and teams2 to the changing environment in a
very flexible and dynamic way [1]. Health authorities have to increase staff for contact tracing
and train auxiliary staff at short notice. Clinics have to increasingly consolidate their nursing
staff in intensive care units, companies have to make work processes suitable for home work
and change their team composition so that the entire company does not come to a standstill
in the event of infections [2, 3]. The concrete requirements for this redesign are constantly
changing due to the parallel process of gaining knowledge about the concrete risk factors in the
spread of the pandemic and require an agile redirection, which is associated with great effort
and uncertainty [3]. From a process perspective, robustness, flexibility, and efficiency must
be weighed against each other in teams [1]. In addition, shifts in business areas can lead to
extreme situations of overload and underload, or to situations where employees in the team
ICCBR POCBR’22: Workshop on Process-Oriented Case-based Reasoning at ICCBR-2022, September, 2022, Nancy, France
*
Corresponding author.
$ mathew@@uni-trier.de (D. Mathew)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
CEUR Workshop Proceedings (CEUR-WS.org)
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
1
we use the term work process and task alternatively to denote the work process in the work
2
we define the term “team” as a set of human resources who are available to perform the work processes.
1
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
are overburdened and under-challenged [2]. Currently, decisions to reorganize teams are often
made “on instinct” without a solid basis for decision-making [1]. More sophisticated tools are
necessary to deal with these challenges and this is the central focus of the FlexiTeam3 project. By
using the data available in organizations on personnel, resources, and organizational processes,
combined with knowledge from cognitive science [4] and industrial psychology [5] as well as
concrete experience from comparable issues in earlier crises, new digital tools can be designed
to support the flexible organization of work teams.
An important source of knowledge for many decisions and thus also for the organization
of the team and work processes is the experiential knowledge. Case-Based Reasoning (CBR)
[7] allows the realization of experience-based problem-solving processes, in which the access
to previous experiential knowledge as well as its adaptation according to the current problem
situation can be (partially) automated. Existing approaches and prototypical systems of the
so-called Process-Oriented Case-Based Reasoning (POCBR) [6] are, due to their rich knowledge
representation, from their basic orientation also suitable for the representation and processing
of experiential knowledge about work processes and the associated team structures. They are
also capable of making suggestions for adaptation in the sense of organization of teams and
work by analyzing larger stocks of experience. This paper is motivated by the research question
- “How can POCBR be applied to flexibly and dynamically organize team and work processes
to be prepared for crises like COVID-19 and what are the research challenges that have to be
addressed for this purpose?”. In this paper, we conceptualize the advances required for POCBR
to cater to the flexible organization of the work processes and human resources in the team.
To address the above research question, we recapitulate the current state of the art in POCBR
in Section 2, we analyze the potential of POCBR for the FlexiTeam problem and identify
the missing part in the case representation of the current state of POCBR using the examples
illustrated in Section 3. We propose a general approach in Section 4 to address the current POCBR
deficits and the novel contribution of this paper includes i) an extended case representation to
represent resources, profiles, and key performance indicators (KPIs) of processes, ii) a query
definition which covers the “context”, i.e. available resources, iii) an overall FlexiTeam process to
flexibly and dynamically organize work processes and human resources. Section 5 presents the
evaluation results using a cooking recipe casebase and analyze the quality of the retrieval using
a quality measure.. In Section 6, we derive the research questions that need to be addressed to
fully explore this approach and the specific difficulties involved in solving this problem.
2. Foundations and Previous Work
POCBR aims at applying CBR methods and principles in process and workflow management.
The workflow modeling involves problem solving activities such as identification and creation
of a suitable workflow process model for a particular scenario. Therefore, it is important to have
a case representation for a workflow and a similarity measure to identify similar workflows.
Bregmann and Gil [8] introduced the NEST graph which is a semantically annotated directed
graph to represent the workflow. It is defined as a quadruple 𝑊 = (𝑁, 𝐸, 𝑆, 𝑇 ) where 𝑁
indicates a set of nodes, 𝐸 denotes a set of edges between nodes in 𝑁 , 𝑆 is a function that
3
we use the abbreviation FlexiTeam to denote the problem of flexibly organizing team and work processes.
2
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
assigns a semantic description to each node and each edge from a semantic metadata language
like ontology and 𝑇 is a function that assigns a specific type to each node and each edge. The
nodes and edges build the structure of each workflow, whereas the semantic information of the
workflow is modeled by the types and the semantic descriptions of nodes and edges.
Consider the example of the sandwich recipe workflow depicted in Figure 1 to demonstrate
the NEST graph representation. In this workflow, the cooking steps are represented in the task
nodes and the ingredients that belong to the corresponding cooking steps are represented as
data nodes. Each workflow graph represents a cooking recipe. The control flow edges connect
the task nodes and it defines the order in which the tasks are executed. The data flow edges
draw connections between task nodes and data nodes. The task nodes consume the inputs
from the data nodes and produce outputs to the data nodes which can be further consumed by
other tasks. Semantic descriptions of task nodes and data nodes are used to specify semantic
information of the workflow components as attribute-value pairs. The semantic description of
the task node Toast is given in the workflow graph. Here, a toaster is needed to execute the
task Toast and it is represented by the attribute name Auxiliaries.
In POCBR, a query is a single partial workflow that represents the tasks, data and structural
relationships of the desired workflow. The user may also want to express the undesired elements
of the workflow. Process-Oriented Query Language (POQL) is the query language developed for
representing the queries of POCBR [9]. A POQL query involves a desired workflow and a set of
restriction workflows. The desired workflow represents the desired properties of the workflow
that is searching for and each restriction workflow represents an undesired situation that can
be avoided. More precisely a POQL query Q = 𝐷𝑊 ∧ ¬𝑅𝑊1 . . . ∧ ¬𝑅𝑊𝑛 where 𝐷𝑊 denotes
the desired workflow and each 𝑅𝑊𝑖 denotes a restriction workflow. For example, consider the
query as searching for a sandwich recipe with tomato and grated cheese, but without grilled
meat. Here the workflow for the sandwich recipe with ingredients tomato and grated cheese is
the part of desired workflow 𝐷𝑊 and the workflow for sandwich recipe with grilled meat as
ingredient is part of a restriction workflow 𝑅𝑊1 .
During case retrieval, similar workflows are identified by finding similarities between the
query workflow and a case workflow. The similarity between the desired workflow and the
case workflow, and the similarity between the restriction workflow and the case workflow are
computed in the same way. Müller and Bergmann [9] adopted the approach from fuzzy logic
[10] to deal with the negations and conjunctions in the POQL query when there are restriction
workflows. To compute the similarity between two NEST graphs, a similarity measure is
required to capture the link structure of nodes and edges as well as the semantic descriptions
and types of these workflow elements. Bergmann and Gil [8] propose a semantic similarity
measure that determines the similarity based on the local-global principle [11]. The global
similarity denotes the similarity between two graphs and it is composed of local similarities
which is the pairwise similarity between nodes and edges.
3. FlexiTeam Workflow Representation
In order to apply POCBR to flexibly and dynamically organize human resources and work
processes during a crisis, we need to consider human resources allocated to the work processes
3
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
R1 Sandwich Recipe
Skills: Chef, Knife skills Duration: 100
Toast Experience: 10 years Preparation Time: 1 hour
Duration: 1 (integer) Sandwich Recipe Sandwich Recipe
Auxiliaries: Toaster (list)
R1 R2
Toast Spread Slice Mix Top
Toast Spread Slice Mix Top
Bread Butter Tomato Sausage Sandwich Top Sandwich
Bread Butter Tomato Sausage Sandwich Top Sandwich
workflow node task node data node controll data part-of
flow edge flow edge edge
workflow node task node data node resource controll data part-of resource
node flow edge flow edge edge edge
Figure 2: FlexiTeam workflow representation
Figure 1: Cooking Recipe Example represented
of cooking recipe
as NEST Graph
in the workflow representation. Here we use an enhanced version of NEST graph to represent
workflow with the details of allocated human resources to each task in the workflow. A new
type of nodes and edges called “resource nodes” and “resource edges” are included to represent
the human resources (e.g. cook) allocated to the work processes. The semantic description of
each resource node contains the profile of the resource which elaborates the skills, experience,
qualification, etc. This profile information can be represented as attribute-value pairs inside the
semantic description of a resource node. For example, a list of skills as value for the attribute
“skills”. A resource edge connects a resource node to the task node to which the resource is
allocated. Figure 2 illustrates an example in the cooking recipe domain where the overall goal is
to prepare 100 Sandwiches and the preparation time is 1 hour. The workflow node describes the
team-related features such as the quantity of work, work duration, etc. as part of its semantic
description. In this example, two human resources named R1 and R2 are allocated to complete
the tasks. These resources are represented as resource nodes R1 and R2. The tasks such as
Toast and Spread are allocated to the resource R1 and the tasks such as Slice, Mix, and Top are
allocated to the resource R2. The profile of the resource R2 is represented as attribute-value
pairs in the semantic description of the resource node R2. There can be different ways in which
the resources and tasks (work processes) can be organized for the same workflow. For example,
a sandwich can be prepared by three human resources where two of them are assigned to do
the tasks such as Toast and Spread and one resource for the other tasks. Each workflow case
represents the structure in which the resources and work processes are organized.
4. FlexiTeam Process Overview
The overall retrieval process to flexibly organize teams and processes may involve the retrieval
of multiple workflows. For example, consider the query as a job to allocate human resources
and organize work processes or tasks to prepare 100 sandwiches and 100 burgers. The workflow
casebase may contain separate workflows for the sandwich recipe and burger recipe. The tasks
such as slicing vegetables and spreading butter can be shared for both sandwich and burger.
4
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
As there can be various combinations of workflows that can match the query goal, it is not
efficient to store all such combinations in the workflow casebase. Hence, there is a need to
split the query into different parts. Thus the retrieval process of FlexiTeam includes - i) define
query to handle subqueries, ii) retrieve workflow for each subquery, iii) combine the retrieved
workflows, and, iv) rank the combined workflows. Section 4.1 discusses the query definition of
FlexiTeam query and Section 4.2 describes the workflow retrieval process.
4.1. Query Definition
A POQL query deals with a desired workflow and several restricted workflows as discussed
in Section 2. However, in FlexiTeam, team organization may involve processes of multiple
workflows. So, a query in FlexiTeam contains multiple desired workflows and restriction
workflows for each desired workflow. Though the features like profiles of available human
resources for the job, work duration, etc. can be represented in the workflow as described
in Section 3, the query may provide overall details of these features instead of individual
details for each subquery. We name such overall features as FlexiTeam features, e.g., resource
profiles available for the entire processes, total work duration. These features are important to
combine the workflows of subqueries and to arrive at an aggregated workflow by matching
the resource profiles. More precisely, the FlexiTeam process query Q can be represented as the
combination of . The Query workflows can be further
decomposed into a set of POQL subqueries {𝑞𝑤1 , 𝑞𝑤2 , . . . 𝑞𝑤𝑚 }. Each subquery 𝑞𝑤𝑖 is defined
as 𝑞𝑤𝑖 = 𝑑𝑤𝑖 ∧ ¬𝑟𝑤𝑖1 ∧ . . . ∧ ¬𝑟𝑤𝑖𝑛 , where 𝑑𝑤𝑖 is the desired workflow of 𝑞𝑤𝑖 and each
𝑟𝑤𝑖𝑗 where 1 ≤ 𝑗 ≤ 𝑛 represents a restriction workflow of query 𝑞𝑤𝑖 . For example, consider
the query “Prepare 50 vegetable sandwiches, 100 vegetable burgers; Available resources: 2
cooking helpers, 2 chefs; and Work duration: 3 hours”. In this example, there are two workflow
subqueries. One for the vegetable sandwich and another one for the vegetable burger. The
FlexiTeam features of this query include i) Available resources, i.e., 2 cooking helpers, 2 chefs
and their profiles, ii) Work duration, i.e., 3 hours
4.2. Workflow Retrieval Process
During the retrieval process, each subquery workflow is represented in POQL language and
top-k similar workflows can be retrieved from the workflow casebase for each query. In the
query example described in Section 4.1, the desired and restriction workflows of each dish
can be represented using the POQL language introduced by Müller and Bergmann [9]. The
similarities between the subquery workflow and the case workflow can be computed using the
ProCAKE framework [12].
We need to combine the workflows retrieved for the subqueries to analyze the FlexiTeam
properties of the overall query. An approach to combining the workflows is to choose a workflow
from the retrieved results of each subquery and merge them. More specifically, choose one
case workflow at a time from the retrieved workflows of a subquery and take 𝑚 such case
workflows for 𝑚 subqueries. For example, one such combination is the case workflow 𝑐𝑤1𝑢
from the retrieved results of 𝑞𝑤1 , 𝑐𝑤2𝑣 from 𝑞𝑤2 , and so on, i.e., (𝑐𝑤1𝑢 , 𝑐𝑤2𝑣 , . . . 𝑐𝑤𝑚𝑤 ) where
1 ≤ 𝑢, 𝑣, 𝑤 ≤ 𝑘. Such a combination of case workflows can be considered as the combined
5
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
Algorithm 1: FlexiTeam Process Algorithm
Input: Q =< QW, TF >
Output: Best combined workflows based on the ranking
1 Decompose the query workflow as 𝑄𝑊 = {𝑞𝑤1 , 𝑞𝑤2 , . . . 𝑞𝑤𝑚 }
2 for each workflow subquery 𝑞𝑤𝑖 do
3 Represent 𝑞𝑤𝑖 as a POQL query; 𝑑𝑤𝑖 ∧ ¬𝑟𝑤𝑖1 . . . ∧ ¬𝑟𝑤𝑖𝑛
4 Retrieve top-k workflows using the POQL query language of 𝑞𝑤𝑖 ; Say 𝑐𝑤𝑖1 , . . . 𝑐𝑤𝑖𝑘 are the top-k
retrieved workflows for the query 𝑞𝑤𝑖
5 Create candidates for the combined workflow by choosing a retrieved workflow of each workflow subquery
6 for each combined workflow candidate do
7 Match the FlexiTeam features of the query with the candidate workflows
8 Estimate the CombinedWorkflowScore
9 Rank combined workflow candidates based on the CombinedWorkflowScore
workflow candidates for the final result of the overall query.
We estimate a score for each combined workflow candidate based on the extent to which
the candidate matches the overall query requirements. Let {𝑞𝑤1 , 𝑞𝑤2 , . . . 𝑞𝑤𝑚 } be the set of
subqueries and the combined workflow candidate of the subqueries be (𝑐𝑤1𝑢 , 𝑐𝑤2𝑣 , . . . 𝑐𝑤𝑚𝑤 )
where 1 ≤ 𝑢, 𝑣, 𝑤 ≤ 𝑘 and 𝑘 denotes the top-k case workflows that are retrieved for each
subquery. The CombinedWorkflowScore is computed as given below.
𝑚
𝛼 ∑︁ (1 − 𝛼) ∑︁
CombinedWorkflowScore = sim(𝑞𝑤𝑖 , 𝑐𝑤𝑖 ) + sim𝑓 (𝑞𝑓 , 𝑐𝑓 )
𝑚 |FlexiTeam𝑓 𝑒𝑎𝑡 |
𝑖=1 𝑓 ∈FlexiTeam𝑓 𝑒𝑎𝑡
(1)
The combined workflow score depends on two factors, i) the aggregation of the similarity
sim(𝑞𝑤𝑖 , 𝑐𝑤𝑖𝑗 ) for each subquery 𝑞𝑤𝑖 where 𝑐𝑤𝑖𝑗 indicates the workflow that is chosen from
the top-k retrieved case workflows for the subquery 𝑞𝑤𝑖 , and, ii) the similarity between the
FlexiTeam features (FlexiTeam𝑓 𝑒𝑎𝑡 ) of the combined workflow candidate and the query.
The overall FlexiTeam process is summarized in Algorithm 1. The lines 1 to 4 describes
the query decomposition into POQL subqueries and retrieval of case workflows for the POQL
subqueries. Line 5 talks about the creation of combined workflow candidates and lines 6 till 8 dis-
cuss the assignment of a score to the combined workflow candidate. Finally, in line 9, combined
workflow candidates are ranked based on the assigned score. The best combined workflows can
be recommended as output based on the ranking of combined workflow candidates.
5. Experimental Evaluation
We synthetically extend the cooking recipe casebase [13] which contains 40 recipes to evaluate
the algorithm proposed in Algorithm 1. We assume that the qualifications of all the resources
who perform the cooking tasks are the same. We create multiple cases from a recipe case in the
existing casebase by adding different combinations of FlexiTeam features such as the resource
nodes, quantity of dishes to be prepared, and the duration to prepare the required quantity of
dish. The work duration and the number of resources are randomly generated between the
ranges of one to four hours and one to ten resources respectively. The quantity of dishes to be
6
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
prepared is calculated using the following formula,
(duration × no. of resources)
quantity = (2)
preparation time for unit quantity
The preparation time for unit quantity is available in the existing case-base. Thus we syn-
thetically generate FlexiTeam features using the preparation time provided in the semantic
description of cases. We generate 15 sets of FlexiTeam features and one set of FlexiTeam query
features for each case or recipe. As we can use the ProCake framework to retrieve the work-
flows, we evaluate only the workflow merging process. We use the FlexiTeam query features
of each recipe as a subquery and assume that the corresponding cases that are generated for
that recipe using FlexiTeam features are the retrieved workflows of that subquery. Hence, the
sim(𝑞𝑤𝑖 , 𝑐𝑤𝑖 ) is always one for all the subqueries. The similarity measure for each FlexiTeam
feature, sim𝑓 (𝑞𝑓 , 𝑐𝑓 ) are given below.
Number of resources and Duration: If the number of resources in the combined workflow
candidate is less than the number of resources in the query, then there is no need to make use
of all available resources. Hence it is a perfect match. If the number of resources in the case
exceeds the number of resources in the query, a linear similarity measure represents how much
more resources are needed than available. This is the same case for the duration feature.
{︃
1 if 𝑐𝑓 ≤ 𝑞𝑓
sim𝑓 (𝑞𝑓 , 𝑐𝑓 ) = (3)
LinearSim𝑓 (𝑞𝑓 , 𝑐𝑓 ) otherwise
Quantity: We use a symmetric measure for the quantity feature (sim𝑓 (𝑞𝑓 , 𝑐𝑓 ) =
LinearSim𝑓 (𝑞𝑓 , 𝑐𝑓 ) ). If the quantity of the case is lesser than that of the query, need to include
more resources based on the quantity difference, and vice versa. 𝐿inearSim is estimated as,
|𝑞𝑓 − 𝑐𝑓 |
LinearSim𝑓 (𝑞𝑓 , 𝑐𝑓 ) = 1 − (4)
MaxValue(f) − MinValue(f)
MaxValue(f) and MinValue(f) are the maximum and minimum values for the feature 𝑓 in the
casebase respectively.
We consider the top-ranked combined workflow candidate as the retrieved workflow and
performed the experiments with the number of subqueries 𝑚 = 2 and 𝑚 = 3 where each
subquery corresponds to a recipe. The FlexiTeam features are generated for each subquery
and they are combined by adding the values of features such as the number of resources and
duration. The quantity of the item of each subquery is considered as a separate feature for the
combined FlexiTeam features. The FlexiTeam features of the combined workflow candidates are
also generated in the same way. The retrieved combined workflow candidate is evaluated across
various retrieval sizes of subqueries (𝑘). We analyze the time complexity with the different
number of subqueries (𝑚) and the different number of cases retrieved for subqueries (𝑘) and it
is illustrated in Figure 3. The complexity of the combination (lines 6-9 in Algorithm 1) depends
on the number of cases retrieved for each subquery, exponentially 𝑂(𝑘 𝑚 ). Thus 𝑘 should be
limited. We also evaluate the average quality of all the top-ranked combined workflows for
all the queries with the values of each combination of 𝑚 and 𝑘. The quality depends on the
7
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
(i) (ii) (iii) (iv)
1.4 1
Average computation time in seconds
𝑚=2 𝑚=2 19 𝑚=2 𝑚=2
% of retrieved cases with the du-
ration value is more than query
9
resources allocated than query
𝑚=3 𝑚=3 𝑚=3 𝑚=3
% of retrieved cases with more
1.2 0.98
18
8
1 0.96 17
Average quality
0.94 16 7
0.8
15
0.92 6
0.6
14
0.4 0.9 5
13
0.2 0.88 12 4
0.86 11
0 3
1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10
No. of cases retrieved for subqueries (𝑘) No. of cases retrieved for subqueries (𝑘) No. of cases retrieved for subqueries (𝑘) No. of cases retrieved for subqueries (𝑘)
Figure 3: (i) Time complexity analysis, (ii) Quality analysis, (iii) Percentage of retrieved cases with more
resources allocated than query, (iv) Percentage of retrieved cases with the more duration than query
formation of the retrieved team and we define it based on the FlexiTeam features such as number
of resources and the duration. The average quality of given values of 𝑘 and 𝑚 is defined as,
1 #Cases#resources(case)>#resources(query) + #Casesduration(case)>duration(query)
avg_quality(k,m) = 1 − ( )
2 #queries
(5)
where #Cases#resources(case)>#resources(query) indicates the number of cases with number of resources
allocated more than that of the query and #Casesduration(case)>duration(query) means the number of
cases with the duration value is more than that of the query. We also analyze the percentage
of retrieved cases with more resources allocated than that of the query and the percentage
of retrieved cases with the duration value is more than that of the query. These analyses are
depicted in Figure 3. We can observe that the quality increases with the increase in the value of
the number of cases retrieved for subqueries (𝑘) till 𝑘 = 4 and then it is almost saturated. The
percentage of retrieved cases with more resources allocated than query decreases drastically till
𝑘 = 4 and then there is not much decrease happen with 𝑚 = 2 and 𝑚 = 3. The analysis of the
duration feature shows that the values are decreasing till 𝑘 = 3. These analyses show that the
value of 𝑘 can be limited to 4.
6. Future Research Directions
We derive the following research questions that need to be addressed to fully explore the
proposed FlexiTeam approach.
1. One future research direction would be to optimize the aggregated workflows by identifying
the shared tasks between case workflows in the combined workflow candidate. It would
be interesting to study such optimization methods while merging the workflows and devise
similarity measures to identify shared tasks. There are studies in Human Computer Interaction
(HCI) to meaningfully decompose tasks during task modelling for interactive system design
[15].
2. There are many similarity measures in the literature to match the skill profiles. In this paper,
we represent the profiles of human resources as part of the workflow [14]. To the best of our
knowledge, this is the first approach to extend the workflow representation to add resource
nodes and their profiles. It would be interesting to derive a similarity measure to match the
resource profiles between workflows by using the properties of the workflows.
3. It is critical to assign work processes to the human resources based on their capability,
8
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
workload, and mental load. It would also be interesting to study the cognitive aspects of team
members such as the collaborative utilization of the technical resources available to the team [16]
and cognitive architectures such as ACT-R [17] to understand how human resources organize
knowledge and produce intelligent behavior during their work.
4. The successful assistance and the integration of AI-based digital systems into existing team
structures and work processes also require graphical user interfaces and interactive visual
interfaces for the transmission of the necessary information by the AI system. This becomes
particularly important in the case of exceptional situations such as the COVID-19 pandemic,
in which all those involved in crisis management are moving on unfamiliar terrain and in a
highly critical situation. By combining POCBR approaches with the methods from HCI, new
possibilities arise for designing experience-based systems as interactive systems that enable
cooperative solution finding in a dialogue between humans and machines.
5. From a human factors perspective, human decision-makers need to accept and trust the
AI-based system to integrate digital expertise in human resource related decision processes.
Research from human-autonomy teaming [18] points out various factors, such as system
knowledge, system reliability, and usefulness, or adaptability. The FlexiTeam process presented
in this paper could not only provide a data basis for the AI, but at the same time, also integrate the
human subsystem in the technical solution and promote user acceptance and development of the
decision-makers. For example, workflow visualizations may serve as externalized shared team
cognition and foster system knowledge. Involving human decision-makers in the definition of
queries and retrieval of workflows will lead to human task reflection and elaboration – both key
processes for team development and adaptation. Thus, future research may investigate how task
changes and user feedback can be continuously integrated into the data-driven decision-making
process to account for team adaptation and stimulate a socio-digital learning process.
7. Conclusion
In this paper, we present an important problem of a flexible team and work organization and
explore POCBR towards solving this problem. We propose a general approach to address the
current POCBR deficits and evaluate the proposed algorithm using a cooking recipe casebase.
The successful assistance and the integration of such AI-based systems into existing team
structures and work processes require not only the analysis of team structures and processes
but also the graphical user interfaces and interactive, visual interfaces for the transmission of
the necessary information by the AI system. It would be interesting to complement AI methods
with methods from HCI and Psychology research to enable successful communication between
human users and the AI system. In this combination, a new form of organizational and business
intelligence can be created to increase resilience in crises, which can create benefits in pandemic
crises as well as in other challenging situations.
8. Acknowledgement
This work has been funded by the Ministry of Science and Health of the German Federal State
of Rhineland-Palatinate.
9
Ditty Mathew et al. ICCBR’22 Workshop Proceedings
References
[1] Boiral, O., Brotherton, M.C., Rivaud, L. and Guillaumie, L.: Organizations’ Management
of the COVID-19 Pandemic: A Scoping Review of Business Articles. Sustainability, 13(7),
p.3993 (2021)
[2] Marin-Garcia, J.A., Garcia-Sabater, J.P., Ruiz, A., Maheut, J. and Garcia-Sabater, J.J.: Op-
erations Management at the Service of Health Care Management: Example of a Proposal
for Action Research to Plan and Schedule Health Resources in Scenarios Derived from the
COVID-19 Outbreak. Journal of Industrial Engineering and Management, 13(2), pp.213-227
(2020)
[3] Vnoučková, L.: Impact of COVID-19 on Human Resource Management. Rev. Latinoam.
Investig. Soc.3, pp. 18–21 (2020).
[4] Stillings, N.A., Chase, C.H., Weisler, S.E., Feinstein, M.H., Garfield, J.L. and Rissland, E.L.:
Cognitive Science: An Introduction. MIT press. (1995)
[5] Tiffin, J. and McCormick, E.J.: Industrial Psychology. (1965)
[6] Minor, M., Montani, S., Recio-García, J.A.: Process-Oriented Case-based Reasoning. Inf. Syst.
40, pp. 103–105 (2014).
[7] Riesbeck, C.K. and Schank, R.C.: Inside Case-Based Reasoning. PLawrence Erlbaum, Hills-
dale, NJ, (1989)
[8] Bergmann, R. and Gil, Y.: Similarity Assessment and Efficient Retrieval of Semantic Work-
flows. In: Information Systems, 40, pp.115-127 (2014).
[9] Müller, G. and Bergmann, R.: POQL: A New Query Language for Process-Oriented Case-
Based Reasoning. In: Proceedings of the LWA, pp. 247-255 (2015).
[10] Burkhard, H.D. and Richter, M.M.: On the Notion of Similarity in Case Based Reasoning
and Fuzzy Theory. In Soft Computing in Case Based Reasoning, pp. 29-45 (2001).
[11] Richter, M.M.: Foundations of Similarity and Utility. In FLAIRS, pp. 30-37 (2007).
[12] Bergmann, R., Grumbach, L., Malburg, L. and Zeyen, C.: ProCAKE: A Process-Oriented
Case-Based Reasoning Framework. In Workshop Proceedings of International Conference
on Case-Based Reasoning, pp. 156-161 (2019).
[13] Müller, G.: Workflow Modeling Assistance by Case-Based Reasoning. In Springer. pp.
I-XVII (2018).
[14] Biesalski, E. and Abecker, A.: Similarity Measures for Skill-Profile Matching in Enterprise
Knowledge Management. In ICEIS (2), pp. 11-16 (2006).
[15] Bowen, J., Dittmar, A. and Weyers, B.: Task Modelling for Interactive System Design: A
Survey of Historical Trends, Gaps and Future Needs. Proceedings of the ACM on Human-
Computer Interaction, 5(EICS), pp.1-22 (2021).
[16] Palmer, T.D. and Fields, N.A.: Computer Supported Cooperative Work. Computer, 27(5),
pp.15-17 (1994)
[17] Ritter, F.E., Tehranchi, F. and Oury, J.D.: ACT-R: A Cognitive Architecture for Modeling
Cognition. Wiley Interdisciplinary Reviews: Cognitive Science, 10(3), p.e1488 (2019)
[18] O’Neill, T., McNeese, N., Barron, A. and Schelble, B.: Human–Autonomy Teaming: A
Review and Analysis of the Empirical Literature. In Human FactorHuman Factors: The
Journal of the Human Factors and Ergonomics Society, pp. 1–35 (2020).
10