TeamEnabler: Towards ad hoc mCRM

Achim P. Karduck and Amadou Sienou

Furtwangen university of applied sciences

Department of Computer Science in Media

Robert-Gerwig-Platz 1, 78120 Furtwangen, Germany

Abstract. Mobile computing technology has reached a level that makes a seam-

less integration of communications and data processing in m-Business applica-

tions possible. The ”connected economy” challenges organizations to reconsider

their business models.

The momentum of the changes can be well-studied in the ﬁnancial sector where

globalization, customisation of expertise and its consideration as ”intellectual as-

sets” are taking place all together. This enables new forms of mobile Customer

Relationship Management (mCRM) that covers the whole value chain and offers

new working modes: formation of geographically dispersed teams of experts for

spontaneous feedback and back ofﬁce work.

In this paper, we have approached the problem of supporting mCRM in a busi-

ness domain requiring dynamic teams of heterogeneous experts. We explain how

mCRM canofferad hoc collaboration spaces to solve complexproblems. Wecon-

sider the concept of the ”Family Ofﬁce” used in the context of ﬁnance as the busi-

ness model for CRM-support. We propose a CSCW (Computer Supported Col-

laborative Work) environment called TeamEnabler which is able to form teams

and to support team work in the scenario of the ”Family Ofﬁce”.

1 INTRODUCTION

Customer Relationship Management (CRM) concerns the life cycle of customer rela-

tions. It deals with questions related to the optimisation of channels, the improvement of

customer acquisition, customer retention, after-sale contracts and services. Generally,

CRM is a cyclic process consisting of ﬁve phases which are (1) collaboration phase

(deﬁned as point of repeated contact), (2) information phase, (3) negotiation phase, (4)

transaction phase and (5) partnership phase [Steimer and Spinner, 2001].

Information and Communication Technology (ICT) increases considerably the num-

ber of communication channels, intermediaries and customer interactions in the con-

texts of CRM. At the same time, CRM is confronted with new challenges concerning

aspects of Collaborative Computing that lead to the progressive emergence of mCRM

(mobile CRM). Here, the main goal is the improvement of coordination for the execu-

tion of complex business CRM tasks with the support of mobile computing.

This investigation focuses on supporting mCRM by providing a mobile application

that enables ad hoc formation of experts and serves as the mobile workspace for het-

erogeneous teams. In this paper, we propose the concept of the ”Family Ofﬁce” for

P. Karduck A. and Sienou A. (2004).

TeamEnabler: Towards ad hoc mCRM.

In Proceedings of the 1st International Workshop on Computer Supported Activity Coordination, pages 164-173

DOI: 10.5220/0002659901640173

 SciTePress

mCRM as the business model to support: Centered on a single contact person, called

the client advisor, further experts join an advisory team in order to manage optimally

and efﬁciently a complex ﬁnancial portfolio. The system supporting this business sce-

nario is called TeamEnabler. Before introducing the TeamEnabler system, let us develop

advanced understandings for the ”Family Ofﬁce” as a business model.

2 THE FAMILY OFFICE FOR AD HOC MCRM

Suppose SAM & associates systems, Inc., an organization of experts, is member of a

worldwide heterogeneous network of ﬁnancial consultants. Michael M., employee of

this company, is expert on insurance questions. The consultant is now in conference

with a customer. Because of the complexity of the problem and the need of advanced

expert knowledge in different domains, Michael M. has decided to connect to the head-

quarter in order to have support in some ﬁelds. In this case, the later have to form a team

of experts that will assist him. Given that Michael M. is equipped with a mobile device,

he would interact directly with the team. For this purpose, an environment for Computer

Supported Collaborative Work (CSCW) is required. It should allow the creation of a (1)

shared workspace, provide (2) assistance for the team formation process, support the

(3) management of the content (documentation of information produced and used) and

enable (4) community support for synchronous and asynchronous collaboration pro-

cesses. These requirements encompass (1) structured support of the team formation,

(2) semi-structured support of content management and (3) weakly structured support

of the collaboration activities. Given that experts solving the problem are geographi-

cally dispersed, mobile technologies should be incorporated. This leads particularly to

scenarios for knowledge intense services that require seamless and spontaneous use of

organization’s expertise.

With TeamEnabler, we want to provide an environment that is able to support the

formation and collaboration of such teams, i.e. team of experts formed in an ad hoc way

to solve information-driven problems in a short time. We call this use case the ”Family

Ofﬁce”. The ”Family Ofﬁce” is a system the inputs of which are customer information

needs that are transformed into knowledge (contextual information as solution of an

information speciﬁc problem). The business process consists of the following 5 steps.

Request for support. When a personal client advisor, called agent, acting for a

company discovers a problem, he/she deﬁnes a request that is sent to the headquarter.

The request consists of the description of the problem, the partial deﬁnition of require-

ments that experts who are going to solve the problem should satisfy and deadlines.

Workspace initialisation. The responsible for the request initiates the creation of a

team-space. Here, the responsible has to specify the requirements by (1) deﬁning roles

that the future team members have to play and (2) the requirements that the proﬁles of

the candidates should satisfy in order to be eligible for a given role. Furthermore, he/she

has to provide a detailed description of the problem, to develop a partial team schedule

and to assign rights and permissions to the roles.

Team building. Based on the roles, schedule and speciﬁcations deﬁned in the pre-

vious step, the real formation is made automatically by the system. In fact, the identiﬁ-

165

cation and the invitation of experts will be supported by a computer-assisted constraint

based approach to team formation operating in expert proﬁles.

Scheduling. Team timer (task coordinator): While collaborating in the team-space,

the elected members deﬁned strategic tasks, operative tasks, detailed schedule and mile-

stone for both, the whole team and single members.

Working. Members work in the team as well as individually in order to produce re-

sults which are listed in the team-space. A team-space or individual workspace of team

members consists of a team view with the strategic goals and a personalized view of the

tasks, schedule, deadlines and deliverables. Currently, in the TeamEnabler environment,

tasks are simply listed. A future extension would be to provide each task with a context

which relates tasks to the overall goals within a team-space, events and activities.

Team Builder

Shared

Community Space

Team Space

Team Timer

(Task coordination)

- community ware

- create teams

- manage members

- create initial documents

- display operative tasks

- display strategic goals

- display appointments

- content management

- personalized view for

each member and team

Shared

Document Space

Fig.1. Modules of TeamEnabler.

The infrastructure supporting the ”Family Ofﬁce” consists of the following basic

modules outlined in Figure 1, illustrating the subsystems and their interrelations.

Shared Document-Space. A (Content Management System) CMS for the semi-

structured management of documents produced and used by the teams; e.g. offers, in-

surance contract and strategies.

Shared Community-Space. Multi-channel communication space for team collab-

oration. Similar to chat-based systems, messages exchanged in the team-space share a

communication context. This context manages (1) the bundling of all messages related

to a given task, (2) events notiﬁed to experts and (3) references from the CMS to the

Community-Space and vice versa.

Team Timer. Deﬁnition and presentation of tasks and appointments, e.g. shared

calendar, list of tasks etc.

Team Builder. Management of a Team-Space. Within this module, the team man-

ager, deﬁnes roles, access rules, requirement speciﬁcation of the project and a partial

team schedule.

166

The workspace is active until the team terminates its activities. The results, mainly

produced documents, are handed over to the requester, in form of hyper-links to the

shared document space of the CMS. The life-cycle of a the team will be characterized by

two kinds of membership: experts executing management tasks like deﬁnition, planning

and coordination of activities and those who are invited in a ad hoc way to solve speciﬁc

problems. The membership of the ﬁrst class of experts is ﬁxed while for the second one,

it is rotating on and off according to tasks requirements.

3 INFRASTRUCTURE AND ARCHITECTURE

3.1 Enabling technologies and applications

Fig.2. Business Needs.

With the emergence of new and less expensive Internet-compliant hardware and

software products targeting on mobile computing, one can expect that m-business sce-

narios rapidly gain importance. In the speciﬁc case of mCRM the emergence concerns

the following four basic interdependent aspects, illustrated in ﬁgure 2.

Content. The content, in the context of the ”Family Ofﬁce” or ”Intellectual As-

sets”, is understood as tangible knowledge like an insurance policy proposal, a client

proﬁle or the contact and schedule information for experts. The ”Intellectual Assets”

exists in form of documents, messages or transactional information like the support

of the team-formation process and general support of workﬂow processes. Concerning

the dimensions ”Information” and ”Communication”, TeamEnabler is based on textual

and graphic information. In the future, multi-modal contents such as voice and video

streams will be available for mCRM-scenarios both, for the knowledge bases and for

the collaboration itself.

Network Devices. Organizations experience the large-scale use of handheld and

wireless devices in business. Predictions [Wireless-Foresight, 2002] support that the

diffusion curve for m-Computing is similar to the one of laptops and the internet into

the workplace.

Needs. Consideration of the application context for ”Individual, Group and Orga-

nization”. Application scenarios supporting the notion of ”Intellectual Asset Manage-

167

ment” will be based on the seamless transition between individual work and group ac-

tivities, both tapping the resources and expertise of the entire organization as required.

Figure 2 shows the dimension ”Network” as the 3

dimension that affects future

application contexts. The spectrum of these technologies is enriched from the tradi-

tional Telco-driven

infrastructures towards computer-based and self-organized infras-

tructures. In addition to cellular networks like GSM

, GPRS

, EDGE

, UMTS

and various emerging technologies [Malladi and Agrawal, 2002], there are several other

overlapping wireless technologies like Bluetooth and WLAN

, which can be used in

an integrated way for mCRM.

Given the importance of seamlessness for the mCRM scenario supported by Tea-

mEnabler, the system should support cellular networks and other wireless technologies

like Bluetooth and WLAN. Based on this brief outline of the technology contexts of

TeamEnabler, the functional components of the layered architecture are explained sub-

sequently.

3.2 TeamEnabler: Architecture

Presentation

layer

Business logic

& application

integration

layer

wireless access

infrastructure

layer

Mobile devices & Application

TeamEnabler

Knowledge

Management

CMS

Server

Community

ware

Team

Builder

Team

Broker

Third party service provider

Network & Services

Fig.3. TeamEnabler Architecture.

The architecture of TeamEnabler is outlined in Figure 3. It is organised into a pre-

sentation layer, a wireless access infrastructure layer and a business logic and appli-

cation integration layer. The core system consists of the modules described in sec-

tion 2 (ﬁgure 1). TeamEnabler implements a CMS and collaboration framework using

the Zope [Zope, 2004] application server and the CMF/Plone portal [Plone, 2004].

Telcos: Telecommunication Companies

GM: Global System for Mobile Communications

GPRS: General Packet Radio Service

EDGE: Enhanced Data Rates for GSM Evolution

Universal Mobile Telecommunications System

WLAN: Wireless LAN

168

Zope is an open source application and Web server based on the programming lan-

guage Python. It offers a CMS-framework for the efﬁcient creation of dynamic web

applications. Interacting with the Appache Webserver, Zope supports database access,

LDAP-access and others open standards like XML-RPC.

Plone, a portal solution, used for the presentation layer, offers a complete CMS solu-

tion. Like Twiki, Plone supports seamlessness offering user management and database

features of Zope. The content Management Framework adds services to Zope in order

to enable community or organization based content management. Plone-Chat is used to

develop the Community-Ware; i.e. the bundling of communication in the team space.

Particularly, the seamlessness between information provision, information access and

information modiﬁcation of Plone ﬁt well into the concept of TeamEnabler. However,

TWiki offers some support for user management including access permissions, which

is needed for the ”Family Ofﬁce”.

The identiﬁcation and the formation of teams into a work space is realized in the

TeamBuilder module.

This module has an extension, called TeamBroker [Karduck and Sienou, 2004], that

matches the requirements speciﬁcation of the team with proﬁles of potential members

of the future team. TeamBroker is described subsequently.

4 FINDING EXPERTS

The team formed in order to provide expertise in the business model of the ”Family Of-

ﬁce” is a virtual one. Basically, virtual teams are networks of people bound by a com-

mon purpose, who work across organizational and temporal boundaries in a collabo-

rative environment supported by information technologies [Lipnack and Stamps, 2000]

like CSCW systems.

Team formation is the process of identifying and the selecting candidates for each

activity of the project in question. Here, the selection of candidates is based on (1) eco-

nomical factors like cost, (2) organisational factors like availability and (3) intellectual

factors like competencies and interests. Subsequent to the identiﬁcation and the concep-

tualisation of factors affecting the formation process, we have considered the following

model to support the formation of teams: the business case is subdivided into tasks able

to be carried out by single experts. A task, in order to be performed, requires a set of

competencies and interests. Experts are entities with interests and competencies who

are looking for positions. Team brokerage consists of ﬁnding experts for a task so that

the positions, the competencies and the interests match. In this model, the team initia-

tor deﬁnes tasks and requirements while experts provide information concerning their

interests, their competencies and the positions in which they are interested.

Since multiple experts may apply to a given task, based on multiple criteria decision

making, we have conceptualised factors affecting the formation of teams by deﬁning

models and metrics able to evaluate experts and teams. The metrics process the perfor-

mance value of a team as an aggregate value of the criteria that really matter during the

formation stage of teams. Based on the conceptualisation of performance values and

the formalization of constraints imposed by the project that a team has to carry out,

169

we have transformed the problem of forming teams into a single resource allocation

problem that has been solved by extending the iterated hill-climbing search strategy.

The TeamBroker system has been realized as a distributed system consisting of Java

RMI (Remote Method Invocation) [Sun Microsystems, 1999] servers.

Initiator

Candidate

publish

binding

lookup

Directory

service

RMI

registry

TeamBroker

binding

TeamInitiator

Proprietary

system

RMI

registry

TeamCandidate

binding

Team brokerage organisation Experts' organisation

Remote method

invocation

Directed

communication

Communication

link

web access

Fig.4. Architecture of TeamBroker.

Figure 4 is the architecture of a technical environment supporting team formation.

The business of the team brokerage organization consists in forming teams of experts

that fulﬁl requirements deﬁned by initiators. It runs TeamBroker RMI servers (1). Ser-

vices provided by TeamBroker are published in a directory server (3). Using this in-

formation, experts identify and select (5) the suitable TeamBroker to which they send

requests for registration. Upon reception of these requests, TeamBroker stores the ref-

erence of the server into its directory (3) by using the RMI registry service provider for

JNDI [Sun Microsystems, 1999].

Experts’ organizationsare networks of experts looking for positions in virtual teams.

Each of them runs a TeamCandidate (4) server, which is extensible to wrappers able to

convert proﬁles described in proprietary formats into the one used in TeamBroker.

The initiator is an organization asking for virtual teams. It is responsible for the

speciﬁcation of requirements that the team should fulﬁls. Initiators access the broker-

age system by using a web-interface (7,8,9). TeamInitiator is a RMI server that repre-

sents a human initiator. For each initiator requesting a registration, the system starts a

TeamInitiator (9), which is bound (10) to the naming service of the broker.

The actual team formation is an interaction between TeamBroker, TeamCandidate

and TeamInitiator. The formation protocol starts when an initiator request the broker to

ﬁnd a team. The team formation protocol is a set of communication messages shared

by TeamBroker, TeamInitiator and TeamCandidate. As outlined in ﬁgure 5, it consists

of the following steps:

170

: TeamBroker

: TeamInitiator

: TeamCandidate

1: request team

2: request application

/inform application

3: query competency

/inform competency

4: query interest

/inform interest

5: inform team

6: request team

enrolment

7: request candidate

enrolment

/inform candidate

enrolment

8: inform team

enrolment

9: inform enrolment

Fig.5. Team formation protocol.

Request team (1). The TeamInitiator requests the TeamBroker to form teams which

fulﬁls requirements deﬁned in the content of the message. The message contains the list

of required positions, schedule, constraints, skills, experiences, interests and budgets.

Request application/Inform application (2). The TeamBroker identiﬁes all poten-

tially interested experts by searching in the directory. In a next step, it requests Team-

Candidate to explicitly apply to the position within a deadline. The message addressed

to the experts contains information concerning the position and the schedule. Instances

of TeamCandidate answer by sending an application message. This message contains

the state of the application, the hourly wage and the level of commitment of the expert.

The state of the application is either ”accepted” or ”rejected”. If the state is ”accepted”

TeamBroker continues the formation process with the TeamCandidate. Otherwise, this

one is no longer considered as a candidate.

Query competency (3)/Query interest (4). During this process, TeamBroker com-

municates with instances of TeamCandidate having accepted the application by sending

an ”inform application” message qualiﬁed ”accepted”. TeamBroker queries instances of

interested TeamCandidate for level of competencies and experiences. The responses are

”inform competency” and ”inform interest” respectively.

Inform team (5). At this stage of the formation protocol, TeamBroker has collected

all information necessary to form teams. The result (teams and performances) is sent to

the TeamInitator.

Request team enrolment (6)/Inform team enrolment (8). TeamInitiator selects

the best team and requests TeamBroker to enroll it.

Request candidate enrolment (7)/Inform candidate enrolment (9). TeamBroker

requests single experts to conﬁrm the enrolment. When an instance of TeamCandidate

receives this message, the expert represented by this instance should decide whether

to join the team or not. If all members agree in the enrolment, the team is deﬁnitively

171

formed and all entities (initiator and candidates) are informed about the success. Other-

wise, a fail message is broadcasted (9).

In TeamBroker, we have emphasized on the formation of virtual teams of humans

by deﬁning the problem as an optimal resource allocation. We have adopted a brokerage

approach consisting of mediating between experts and the team requestor.

5 RELATED WORK

Parlano [Parlano, 2004] is a commercial enterprise collaboration environment, that closely

matches to the concept of the Community and Content Management features of Tea-

mEnabler. Initially, it has been focused on instant messaging between traders, includ-

ing ﬁlter mechanisms, persistence, alerts and icon menus for the organization of work-

spaces. It’s work-space consists of a message exchange space (task oriented commu-

nity) and content management space. Similar to TeamEnabler, here the bundling of

message exchanges constitutes an additional communication channel e.g. to simple

Email-systems.

TeamEnabler enhances the model of Parlano with the concept of the ”Family Of-

ﬁce”. This concept, derived from Finance, supports the formation process of a team of

experts, based primarily on the expertise required to solve a task. The ad hoc formation

of a team is supported by inviting experts into the work-space or by automating the pro-

cess through the TeamBroker-mechanisms. Referring to mCRM, in contrast to existing

systems, TeamEnabler supports experts working directly with a customer. Supporting

the whole lifecycle of CRM by integrating seamlessly team formation, cooperation and

advise oriented processes is, as far as the authors know, a novice business case for CRM

systems.

6 CONCLUSION

The work on CSCW-support for the ”Family Ofﬁce” concept will be extended accord-

ing to the ”3C Collaboration Model (Communication, Coordination, Cooperation)”

[Fuks and de Lucena; C. J., 2004]. Especially coordination will be investigated in two

aspects: awareness of the team members concerning the individual activities and com-

mitment in terms of the delegation of individual responsibilities. Advanced investiga-

tions are necessary in order to integrate these aspects in the business case. This should

enable dynamic and continuous activities of coordination during experts’ cooperation.

Technically, we plan to extend the current TeamEnabler by enabling interactions

with a directory service. Within the directory server, organizational structures and re-

sponsibilities will be managed in standardized infrastructures.

In the context of TeamBroker, we have (1) conceptualized factors and performance

values affecting the formation of teams, (2) formalized constraints imposed by the

project that a team has to carry out, (3) transformed the problem of forming teams into a

resource allocation problem and (4) solved it by using methods of constraints program-

ming. We plan an higher integration of TeamBroker into the TeamEnabler environment

by adopting a service oriented architecture.

172

The current version of TeamEnabler supports reduced spectrums of the ”Family

Ofﬁce”: it offers a simple collaboration environment. In future work, we intend to track

information of the team space ”for ever” by providing an environment the content of

which evolves with the customer lifecycle. That means, old team spaces are not going to

be deleted; they should rather be considered for future consulting sessions of the same

customer (even if the consulting teams differ). By the same way, the result of team work

should ﬂow into the proﬁles of the experts in order to facilitate automatic selection of

experts. It should be therefore possible to update experts proﬁle while working in the

team space and to develop a dynamic history of customer’s lifecycle. The new features

will lead us to position mCRM within the context of Knowledge Management. Instead

of Knowledge Management, we will use the term of ”Intellectual Asset Management”,

borrowed from the ﬁnancial domain. In Finance, Asset Management is the key activity

for managing a ﬁnancial portfolio according to the deﬁned risk proﬁles and targets of a

client. In the long perspective, we try to apply gradually this approach for collaborative

work support.

References

[Fuks and de Lucena; C. J., 2004] Fuks, H.; Raposo, A. B. G. M. A. and de Lucena; C. J., P.

(2004). Applying the 3c model to groupware engineering. Monograﬁas em Cincia da Com-

putao, (1).

[Karduck and Sienou, 2004] Karduck, A. P. and Sienou, A. (2004). Teambroker: Constraint

based brokerage of virtual teams. In Proceedings of sixth International Conference on En-

terprise Information Systems (ICEIS 2004), Porto, Portugal.

[Lipnack and Stamps, 2000] Lipnack, J. and Stamps, J. (2000). Virtual Teams. John Wiley &

Sons, 2 edition.

[Malladi and Agrawal, 2002] Malladi, R. and Agrawal, D. (2002). Current and future applica-

tions of mobile and wireless networks. Communications of the ACM, 45(19):144–146.

[Parlano, 2004] Parlano (2004). Parlano. http://www.parlano.com (access 10.02.2004 13:00).

Parlano Enterprise Collaboration Solution.

[Plone, 2004] Plone (2004). Plone. http://www.plone.org (access 10.02.2004 20:30).

[Steimer and Spinner, 2001] Steimer, F.; Maier, I. and Spinner, M. (2001). mCommerce. Addi-

son Wesley, Mnchen.

[Sun Microsystems, 1999] Sun Microsystems, I. (1999). Java technologies.

http://www.java.sun.com/jndi, http://www.java.sun.com/rmi (access 10.10.2002 09:00).

[Wireless-Foresight, 2002] Wireless-Foresight (2002). Scenarios of the mobile world in 2015.

http://www.innovationwatch.com. /scenarios

tech 2015.htm (access 10.02.2004 10:00).

[Zope, 2004] Zope (2004). Zope. http://www.zope.com (access 10.02.2004 10:30).

173