Tải bản đầy đủ - 0 (trang)
3 Conclusion: Factors to Be Investigated

3 Conclusion: Factors to Be Investigated

Tải bản đầy đủ - 0trang

Crowdsourcing in Business Process Outsourcing



39



Table 1. (Continued)

Origin

Decision on BPO in

general (Sect. 3.1)



Factor

Core

Competence

COMP



High service

quality

QUAL



Loss of

management

control

CTRL



Cost

Decision on BPO in

savings/budget

general (Sect. 3.1) and

COST

Crowdsourcing

(Sect. 3.2)



Security

risk/sensitive

information

SECU



Flexibility,

Availability of

internal HR

FLEX



Description

Indicator: Is the task to be

outsourced a core competence

of the enterprise? [Yes, No]

Core competence should not be

outsourced

Indicator: Is the expected service

quality provided by outsourcing

higher than the quality achieved

internally? [Yes, No]

Significantly better service results

motivate outsourcing

Indicator: Does outsourcing lead

to a not-acceptable loss of

management control? [Yes, No]

The business process has to be on

an acceptable level under

management control, both

within the enterprise or when

outsourced

Indicators: Saving per time

period; availability of budget

Outsourcing makes only sense of

it leads to cost savings and is

only possible if the

organization has fund to pay for

it

Indicator: Is either data related to

the service, the resources used

or the process applied subject to

confidentiality? [Data,

Resource, Process, None]

Confidential data, resources,

processes should not be

exposed to actors outside the

enterprise

Indicator: Are enough human

resources available in-house?

Does outsourcing increase the

flexibility of internal resource

use? [Yes, No]

In case of (temporary) shortage of

capacity, outsourcing can

provide higher flexibility than

increasing internal resources



Lit.

[8, 9, 23]



[8, 9, 23]



[8, 9, 23]



[8, 9, 23]



[8, 9, 23]



[8, 9, 23]



(Continued)



40



K. Sandkuhl et al.

Table 1. (Continued)



Origin

Crowdsourcing

(Sect. 3.2)



Factor

Ease of task

decomposition

DECO



Description

Indicator: Can the task be easily

decomposed into subtasks that

could be solved independently?

[Yes, No]

Decomposition is important to

speed up task execution by

parallelizing it

Indicator: Whether this task and

Possibility to

its expected result can be

deliver task

delivered through the internet

through the

internet; INTN Crowd computing uses network

interaction as its primary

information channel

Indicator: A number of people in

Interaction

organization that usually

between

influence task completion or the

organization and

number of inner organization

members

resources and instructions that

INTA

need to be used for task

completion

Tasks that are relatively

independent of the

organization’s information

infrastructure are easier to

crowdsource

Indicator: Is the estimated number

Availability of

of crowd members (of a

crowd members

particular crowd provider) able

needed for task

to complete the task sufficiently

CMAV

large?

Some tasks require special skills

that are incompatible with a

usual demographics of crowd

members

Coordination

Indicator: Ability to handle

COOR

coordination of crowd workers

The presence of management staff

able (from the skill perspective

as well as from the working

schedule perspective) to

coordinate crowd computing

effort can result in better

performance



Lit.

[1, 13, 17]



[1, 17]



[15, 17]



[1, 15, 17]



[1, 12, 17]



(Continued)



Crowdsourcing in Business Process Outsourcing



41



Table 1. (Continued)

Origin



Factor



Description



Risk

RISK



[12, 17]

Indicator: Can the organization

embed the risk of low quality

crowdsourcing result to its risk

management scheme?

The result of crowdsourced task

can be of relatively low quality,

and if it is critical for the

organization, then

crowdsourcing probably should

be avoided, or engineered in a

more careful way

Indicator: Does the organization [1, 15, 17]

possess its own crowd

platform/typical pool of crowd

members

The availability of crowdsourcing

platform can decrease cost



Platform

PLAT



Lit.



4 Case Study: BPO in Energy Sector

This section summarizes the design, content and results of a case study on business

process outsourcing which was performed in the utilities industry. The purpose of the

case study was twofold: On the one hand we intended to study business process

outsourcing and the options to use crowd sourcing in a real-world context in order to

understand the specifics of this area. On the other hand, we wanted to analyze the

factors identified in the literature study in the context of the case study data. The

question to investigate is whether the case study indicates that the factors really can be

considered as affecting the decision on business process outsourcing into the crowd.



4.1



Case Study Design



In order to investigate the field of business process outsourcing, we had the possibility

to study a business services provider from the energy sector. Within this business

service provider (BSP), we collected information about BPO in several ways:

• One researcher worked during 3 months two or three working days every week at

the BSP’s facilities. The researcher was part of the team operating the business

service and maintaining the SaaS platform used for provisioning the services to the

service provider’s clients. The researcher maintained a work diary and collected

information about the work processes, technologies used and practices by observing

the co-workers and taking notes. The management of the BSP agreed to this procedure and the co-workers were informed about the purpose of the data collection.



42



K. Sandkuhl et al.



• The BSP specifies the services to be provided to the clients by defining business

process models. These models have to be kept accurate and up-to-date since they

are used to create executable workflows. Some of the models were accessible to the

researchers and could be analyzed.

• The internal business processes at the BSP, which were performed for delivering the

business process service to the clients, were captured by interviewing different roles

in the BSP. The roles interviewed were the service owner (responsible for the

features of the service and the flow of activities in it), knowledge worker (performing manual activities in the process), system operator (responsible for configuring and managing the infrastructure platform) and the BSP manager

(responsible for acquisition of clients, analyzing their demands and setting up the

service level agreements). In total six interviews were performed as expert interviews [2] guided by a list of questions related to the propositions (see below).

The main subject to investigate was “How are BPO services delivered by a BSP to

its clients in terms of processes performed, organization structure used, technology

applied and information used”. As already indicated in Sect. 2, the character of the case

study is descriptive. Furthermore, we defined two propositions P1 and P2.

• P1: The case shows the potential for outsourcing some of the tasks performed

within the BPO services to the crowd.

• P2: Factors identified in the literature study can be observed in the case study.

To set clear boundaries for the case we defined that only data collected during the

three months work of the researcher (see above) at the BSP’s facilities (including the

process models and interviews) in the organization units responsible for service provision to clients in the energy sector and for SaaS maintenance shall be taken into

account. Not subject of the case study are other organization units of the BSP, BPO

services provided to other utility industries (water, gas, etc.), the clients of the BSP and

sub-suppliers used for BPO by the BSP.



4.2



Summary of Case Study Data



Due to the space limitations only a summary of the data collected in the case study can

be presented in this paper. In this summary, we inserted the codes defined for the

factors (see Table 1), e.g., [FLEX] for the factor “flexibility”, if the information collected can be linked to the factors. This “linking to codes” will be used in Sect. 4.3

when evaluating the case study data.

The BSP studied in the case study is a medium-sized enterprise from Germany

which offers more than 20 different BPO services to their clients. The target group for

these services is medium-sized utility providers and other market roles of the energy

sector in Germany and several other European countries. Many energy distribution

companies are outsourcing some business functions and business processes connected

to these functions. Examples are meter readings, meter data evaluation, automatic

billing, processing and examination of invoices, customer relationship management

and order management. The motivation of these companies for outsourcing business



Crowdsourcing in Business Process Outsourcing



43



processes is twofold: Some companies use BSP is to temporarily increase the capacity

for performing the processes, as they do not have sufficient internal resources for

certain high capacity periods [FLEX]; others want to minimize efforts for adaptation to

market or legal changes [COST]. Energy companies in Germany are facing a continuously changing business environment due to new regulations and due to competitors

implementing innovative technical solutions, like intelligent metering or grid utilization

management. In this context, both the business processes in organizations and information systems supporting these processes need to be quickly adaptive to changing

organizational needs [FLEX].

The BSP offers the performance of a complete business process for a business

function or only of selected tasks of a business process. In this context, the BSP has to

offer and implement solutions for different variations of these business processes or

tasks. One variation is inherent in the business process as such. Even though core

processes can be defined and implemented in standard software systems, configurations

and adjustments for the organization in question are needed. The second cause of

variation is the configuration for the country of use, i.e., the implementation of the

actual regulations and bylaws. The third variation is related to the resource use for

implementing the actual business process for the customer, i.e., the provision of

technical and organizational capabilities.

The IT-basis for these services in our case study is a software product which was

developed and is maintained by the BSP. Integrated with a workflow engine and

business activity monitoring, this software product provides the business logic for the

energy sector, which is implemented using a database-centric approach. In addition to

this software product, other cloud-based services for information exchange, document

management and security are integrated [CPLX]. Different deployment models are

used including a provider-centric model (the software product and the business processes are run at the BSP’s computing center), a client-centric model (the software

product is installed at the client site and the manual work of the business process is

performed at the BSP) and mixed models (e.g., the software product is offered in the

cloud, work and process are performed partly at the client and partly at the BSP)

[DEPL] [INTN].

An example business process, which is offered as BPO service and consists of

various activities [DECO], is to process information about energy consumption based on

meter readings. This information is exchanged between different market roles in the

energy sector using EDIFACT-like messages. Each file exchanged between the market

roles might contain thousands of messages which in turn follow a defined syntax with a

multitude of constraints and rules regarding the semantics of the information included.

The processing of the files and messages is only a small part of the process. More efforts

and activities are caused when errors are detected in the messages or exceptions are

discovered due to violation of constraints and rules. In these cases, the automatic processing is interrupted and human intervention required. The competence required from

the “knowledge workers” ranges from simple correction of syntax errors or substitution

of faulty codes to remedy of so far unknown exceptions which requires expert knowledge from the energy sector and the IT services used. This expert knowledge is considered as one of the most important competitive advantages [COMP].



44



K. Sandkuhl et al.



BSP and client have an agreement which defines the capacity to be provided, the

cost model, levels of confidentiality [SECU] and service quality. The BSP is responsible for providing the contractually agreed capacity and quality. Sub-suppliers will

only be integrated if the agreement with the client does not exclude this option [SECU]

and if they provide the required quality of the service [QUAL] [RISK]. So far, no

experience with crowdsourcing exists. The BSP can imagine evaluating crowdsourcing

techniques for specific, isolated tasks [INTA] with low training efforts, like the correction of error codes, when there is a lack of own capacity [FLEX]. Precondition

would be the availability of a defined group of people with known competences

[COMP] [CMAV] who flexibly could be integrated into service provision. Furthermore, the status of the contributions from the crowd should be transparent [CTRL] and

it should be economically rewarding [COST].

The maintenance process encompasses steps for designing, developing, deploying

and operating the software systems used for BPO. The case showed three different

phases in the maintenance process:

• The conceptual solution addresses the development of business services which fit to

the strategic objectives and meet the practical demands of the customer under

consideration. Focus here is on the business logic, not on the technical implementation [COMP].

• The technical solution prepares the conceptual solution for execution. This usually

requires an enhancement or refinement of the conceptual solution when adapting it

for a specific technical platform for execution [CPLX],

• The executable solution represents the technical solution deployed on a specific

platform. This “running system” is managed by the customer that uses it or by a

service provider [DEPL].

The technology stack encompasses all IT-tools and platforms requires for the above

phases of the engineering process. This includes tools and notations or languages for

modeling the conceptual solution, like process modeling, business process management

or enterprise modeling tools, workflow engines and process execution environments as

well as software development environments in case services or software components

have to be integrated, and operating platforms and monitoring tools used during execution of the solution [CPLX].



4.3



Case Study Analysis



The main technique for analyzing the case study data was to link the data to the

propositions. Thus, we will discuss both propositions in the light of the case study data.

As both propositions are related to the factors identified in Sect. 3 and summarized in

Sect. 3.3, we will start the analysis by providing an overview what information is

visible in case study data regarding the factors. This summarized in Table 2.

For some factors, there was no or not enough information available in the case

study to decide on their relevance: ability to handle coordination of crowd workers,

availability of an own crowd platform to the organization and the required number of

knowledge workers to handle a given case.



Crowdsourcing in Business Process Outsourcing



45



Table 2. Factors and their presence in case study data

Factor

Description

Factors whose relevance for decision making about crowdsourcing in the case study was

confirmed

Complexity of cloud service

The architecture in the case study consists of the BSP’s

architecture

software product and – depending on the client – of

potentially additional software service. In case of

additional software, outsourcing to the crowd is

considered more difficult.

Core Competence

Tasks requiring expert knowledge will not be outsourced,

since this is considered as competitive advantage which

the BSP protects

High service quality

Precondition for considering crowdsourcing for certain

activities is that the service level agreement with the client

can be kept

Loss of management control

The responsible persons for service management require

transparency regarding status and performance of the

crowd-members

Cost savings/budget

Crowd sourcing would only be considered if it is

economically rewarding

Security/sensitive information

If the contract with the client excludes an outsourcing

option, the BSP will not include any kind of sub-supplier

Flexibility, HR availability

Precondition for considering crowdsourcing would be a lack

of internal capacity

Deliver task with Internet

In the case study, all parts of the outsourcing are provided

using Internet technology

Availability of crowd

Crowdsourcing would require a defined group of people

members

with known competences

Interaction of organization

Only specific and isolated tasks will be considered for

and crowd members

outsourcing

Risk

Precondition for considering crowdsourcing is that the

service level agreement with the client can be kept, i.e., no

risk of too low quality

Required level of adaptation

If an exception requires special adaptation of the case

handling it will not be considered for outsourcing

Factors whose relevance was not confirmed by the case study

Deployment model

In the case study, deployment in one or several private

clouds was possible. Crowd members would be awarded

access right to specific private cloud

Ease of task decomposition

In the case study, the overall business process is already

decomposed into single tasks. Decomposition was not

considered.



P1: The case shows potential for outsourcing some of the tasks performed within

the BPO services to the crowd. Both the case study data and the evaluation of factors in

Table 2 show that the case shows the possibility for involving crowd-members in



46



K. Sandkuhl et al.



provisioning the BPO service. The potential for crowdsourcing seems quite limited

since it is only for “simple” tasks in exception handling which require limited training

efforts for a known group of crowd-members. Furthermore, the BSP does not have

experience with crowdsourcing and will consider this as an “experiment”, which

indicates that the subject so far is given low priority. However, for the research work

presented in this paper it is important to notice that due to the potential for using

crowdsourcing it was a suitable case study for investigating the factors identified in the

literature study.

P2: Factors identified in the literature study can be observed in the case study.

Table 2 shows that most of the factors actually could be observed in the case study and

most of them were confirmed relevant. Only two factors were not confirmed:

deployment model and ease of task decomposition. For these two factors, which

intuitively make sense, we will need to investigate further cases in order to decide on

their pertinence.



5 Summary and Future Work

Based on a literature study in the areas of BPO and cloud computing and crowdsourcing, this paper identified potential factors relevant for decision making in favor or

against using crowdsourcing in BPO scenarios. The factors identified were investigated

in a case study from business process outsourcing, which confirmed many of the factors

and gives reason to believe that the work contributes to a better understanding of

outsourcing decisions in BPO and the relevant factors. However, just one case study

will not give a conclusive picture whether the identified factors can be assumed to be

relevant for the majority of BPO cases. Future work will have to investigate more

cases. The factors identified have to be considered as a theory contribution grounded in

literature and one case study.

Research including empirical studies has threats regarding its validity, and so has

the case study performed in this paper for investigating the decision factors for crowd

sourcing. However, to early identify such threats and to take actions to mitigate the

threats can minimize the effect on the findings. Common threats to empirical studies are

discussed, for example in [20] and [23]. The threats to validity can be divided into four

categories: construct validity, internal validity, external validity and conclusion

validity. Construct validity is concerned with obtaining the right indicators and measures for the concept being studied. Internal validity primarily is important for

explanatory studies with the objective to identify causal relationships. External validity

is addressing the question about to which extent the findings in a study can be generalized. Conclusion validity addresses repetition or replication, i.e., that the same

result would be found if performing the study again in the same setting.

With respect to construct validity, the following threats were identified and actions

taken: (a) Selection of employees from the BSP interviewed and observed in the case

study. The results are highly dependent on the people being interviewed and observed.

Only persons experienced in business process outsourcing and the application domain

under consideration will be able to contribute to judging the importance of factors. To

obtain the best possible sample, only people having worked in this area for a long time



Crowdsourcing in Business Process Outsourcing



47



and hence having the required background were interviewed or observed during the

case study. (b) Reactive bias: A common risk in studies is that the presence of a

researcher influences the outcome. Since the selected participants in the study and the

researcher performing the study have been collaborating for a long time, this is not

perceived as a large risk. However, as the crowdsourcing idea was proposed by the

researcher there is the risk that the interviews are biased towards this idea and to find

evidence for the relevance of factors. In order to reduce this threat, the interviewees

were informed that crowdsourcing can be used in different ways and the purpose of the

study was to investigate feasibility. (c) Correct interview data: There is a risk that the

questions of the interviewer may be misunderstood or the data may be misinterpreted.

In order to minimize this risk, the data collected during the interviews was presented

afterwards to the interviewees to allow for verification. Furthermore, the interviews

were documented, which allowed the researcher to check certain parts of the interview

again if portions seemed unclear.

From the perspective of external validity, a potential threat of the study is of course

that the actual interviews and observations have been conducted with members of only

one BSP. It will be part of the future work, to conduct a study with other BSPs.

Conclusion validity mainly concerns the interpretation of data: The outcome of the

study potentially could be affected by the interpretation of the researcher. To minimize

this threat, the study design includes capturing the relevant aspects by different data,

i.e., to conduct triangulation to check the correctness of the findings. Furthermore,

another risk could be that the interpretation of the data depends on the researcher and is

not traceable. To reduce the risk the data interpretation was discussed with other

researchers and validated by them.

In addition to more case studies and the collection of additional data regarding the

identified factors, future work has to contribute a deeper conceptualization of the

different factors. We identified factors and confirmed their pertinence in one case, but

we did not fully operationalize them. For factors like architecture of cloud service, we

will need to spend more work on finding indicators which show, when the factor under

consideration has substantial influence and when the influence is negligible. For the

example of the factor “cloud service architecture” this would mean to determine, with

which indicator to measure this factor and what indicator values would have to be

considered too high for a decision in favor of outsourcing. Another direction of the

future work is to separately evaluate each factor’s influence for different crowdsourcing

models, as the employed model (e.g., microtask markets, solution contests) may affect

factor’s relevance.

Acknowledgements. Parts of the research were supported by the EU FP7-project CaaS (project

# 611351). Other parts were partially supported by grants # 14-07-00345, # 16-07-00466 of the

Russian Foundation for Basic Research, and by Government of Russian Federation, Grant

074-U01.



48



K. Sandkuhl et al.



References

1. Afuah, A., Tucci, C.L.: Crowdsourcing as a solution to distant search. Acad. Manag. Rev.

37(3), 355–375 (2012)

2. Bogner, A., Menz, W.: The theory-generating expert interview: epistemological interest,

forms of knowledge, interaction. In: Bogner, A., Littig, B., Menz, W. (eds.) Interviewing

Experts, pp. 43–80. Palgrave Macmillan UK, London (2009)

3. Buecheler, T., et al.: Crowdsourcing, open innovation and collective intelligence in the

scientific method: a research agenda and operational framework. In: Artificial life XII.

Proceedings of the twelfth international conference on the synthesis and simulation of living

systems, Odense, Denmark (2010)

4. Howe, J.: The rise of crowdsourcing. In: Wired magazine, pp. 1–4. Dorsey Press (2006)

5. Howe, J.: Crowdsourcing: a definition (2006). http://crowdsourcing.typepad.com/cs/-2006/

06/crowdsourcing_a.html. Accessed 27 Nov 2014

6. Jansen, W., Grance, T.: Guidelines on security and privacy in public cloud computing. NIST

special publication SP 800-144 (2011)

7. Krogstie, J.: Model-Based Development and Evolution of Information Systems - A Quality

Approach. Springer, London (2012)

8. Lacity, M.C., Willcocks, L.P.: An empirical investigation of information technology

sourcing practices: lessons from experience. MIS Q. 22(3), 363–408 (1998)

9. Lacity, M., Willcocks, L.P.: Information Systems and Outsourcing: Studies in Theory and

Practice. Palgrave, London (2009)

10. Motahari-Nezhad, H.R., Stephenson, B., Singhal, S.: Outsourcing business to cloud

computing services: opportunities and challenges. IEEE Internet Comput. 10(4), 1–17

(2009)

11. Rimal, B.P., Choi, E., Lumb, I.: A taxonomy and survey of cloud computing systems. In:

NCM 2009, Fifth International Joint Conference on INC, IMS and IDC, pp. 44–51 (2009)

12. Rouse, A.C.: A preliminary taxonomy of crowdsourcing. In: ACIS 2010: Information

Systems: Defining and Establishing a High Impact Discipline: Proceedings of the 21st

Australasian Conference on Information Systems. ACIS (2010)

13. Schenk, E., Guittard, C.: Towards a characterization of crowdsourcing practices. J. Innov.

Econ. 2011(1), 93–107 (2011)

14. Seigerroth, U.: Enterprise modeling and enterprise architecture: the constituents of

transformation and alignment of business and IT. IJITBAG 2(1), 16–34 (2011)

15. Sharma, A.: Crowdsourcing Critical Success Factor Model: Strategies to Harness the

Collective Intelligence of the Crowd. Working paper (2010)

16. Thuan, N.H.: To establish crowdsourcing as an organizational business process: an

exploratory study. Phd Research Proposal, School of Information Management, Victoria

University of Wellington, New Zealand (2013)

17. Thuan, N.H., Antunes, P., Johnstone, D.: Factors influencing the decision to crowdsource.

In: Antunes, P., Gerosa, M.A., Sylvester, A., Vassileva, J., Vreede, G.-J. (eds.) CRIWG

2013. LNCS, vol. 8224, pp. 110–125. Springer, Heidelberg (2013)

18. La Vecchia, G., Cisternino, A.: Collaborative workforce, business process crowdsourcing as

an alternative of BPO. In: Daniel, F., Facca, F.M. (eds.) ICWE 2010. LNCS, vol. 6385,

pp. 425–430. Springer, Heidelberg (2010)

19. Vicente, K.J.: Cognitive Work Analysis: Toward Safe, Productive, and Healthy

Computer-Based Work. CRC PressI LLC, Boca Raton (1999)

20. Wohlin, C., Runeson, P., Host, M., Ohlsson, C., Regnell, B., Wesslèn, A.: Experimentation

in Software Engineering: An Introduction. Kluver Academic Publishers, Norwell (2000)



Crowdsourcing in Business Process Outsourcing



49



21. Woitsch, R., Karagiannis, D., Plexousakis, D., Hinkelmann, K.: Business and IT alignment:

the IT-Socket. e & i Elektrotechnik und Informationstechnik 126(7–8), 308–321 (2009)

22. Yang, D.H., Kim, S., Nam, C., Min, J.W.: Developing a decision model for business process

outsourcing. Comput. Oper. Res. 34(12), 3769–3778 (2007)

23. Yin, R.K.: Case Study Research: Design and Methods. Applied Social Research Methods

Series, vol. 5, 3rd edn. Sage Publications Inc, Thousand Oaks (2002)

24. Zhao, Y., Zhu, Q.: Evaluation on crowdsourcing research: current status and future direction.

Inf. Syst. Front. 2012, 1–18 (2012)



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

3 Conclusion: Factors to Be Investigated

Tải bản đầy đủ ngay(0 tr)

×