Crowdsourcing in BPO: Strategic Flexibility or Operational Risk?

Crowdsourcing in Business Process Outsourcing: An Exploratory Study on Factors Influencing Decision Making

2016-01-01
Kurt Sandkuhl, Alexander V. Smirnov, Andrew Ponomarev
Summary
Problem
Method
Results
Takeaways
Abstract

This paper explores the feasibility of integrating crowdsourcing into Business Process Outsourcing (BPO) within cloud computing environments. It identifies a set of decision-making factors through a multifaceted literature review and validates them via a descriptive case study of a Business Service Provider (BSP) in the energy sector.

TL;DR

Is "the crowd" ready for the rigorous demands of Business Process Outsourcing (BPO)? This exploratory study identifies 17 critical factors—ranging from cloud architecture complexity to core competence preservation—that determine whether a business process task should be sent to an undefined online group. Through a deep-dive case study in the energy sector, the research reveals that while crowdsourcing offers a powerful "pressure valve" for volume spikes, it remains strictly gated by security requirements and the need to protect proprietary "expert" knowledge.

Contextual Positioning

In the landscape of Cloud Computing, we often discuss SaaS (Software) and PaaS (Platform), but BPaaS (Business Process as a Service) is where the human-machine interface becomes critical. This paper sits at the intersection of traditional outsourcing theory and modern "Crowd Computing," seeking to turn intuitive management "gut feelings" into a structured decision-making framework.

The Core Challenge: The Flexibility-Scalability Gap

Standard BPO models struggle when automated systems fail and manual intervention is required at scale (e.g., correcting thousands of erroneous energy meter readings). Hiring internal staff for these "exception handling" spikes is too slow and costly. Crowdsourcing seems like the logical solution, but managers fear:

  1. Loss of Control: Can we trust the quality of an anonymous crowd?
  2. Security Leakage: Does the process involve sensitive customer data?
  3. Architecture Friction: Is our IT stack too complex to allow external crowd access?

Methodology: Bridging Theory and Practice

The authors conducted a dual-track investigation. First, they distilled a "Candidate Factor Table" from existing literature. Second, they embedded a researcher within a German Energy BSP for three months to validate these factors against actual business workflows.

The Decision Matrix

The study categorizes factors into four origins:

  • Cloud Computing: Architecture complexity and deployment models (Public vs. Private).
  • General BPO: Cost savings, core competencies, and management control.
  • Crowdsourcing Specifics: Task decomposition ease and internet deliverability.
  • Combined Risks: Security and the "Interaction" frequency between the crowd and the home organization.

Table of Factors Influencing Crowdsourcing Decisions

Deep Dive: The Energy Sector Case Study

The researchers analyzed a BSP managing 20+ services for utility providers. A prime candidate for crowdsourcing was identified: Exception Handling in EDIFACT Message Processing.

  • The Scenario: Automated systems process energy consumption files. When a syntax error occurs, a human must intervene.
  • The Finding: Simple syntax corrections (non-core) are perfect for the crowd. However, diagnosing "unknown exceptions" requires deep domain expertise—a Core Competence that the company refuses to outsource to protect its competitive edge.

Key Experimental Validation

The study confirmed that Security/Sensitive Information [SECU] acts as a hard gate: if the client contract forbids third-party handling, crowdsourcing is dead on arrival. Conversely, Flexibility [FLEX] was the primary driver; the crowd isn't just about being cheaper, but about being available when internal HR is at capacity.

Confirmed Factors in Case Study Analysis

Critical Analysis & Conclusion

Takeaway

The paper successfully transitions crowdsourcing from a "gig economy" buzzword to a legitimate architectural component of BPaaS. The insight that Cloud Architecture Complexity [CPLX] directly correlates with crowdsourcing difficulty is particularly vital for CTOs—if your SaaS stack is a "spaghetti" of integrations, you cannot easily onboard a dynamic crowd.

Limitations

As an "exploratory" study, its reliance on a single case study in Germany limits its global generalizability. Furthermore, the paper lacks "Operational Thresholds"—it tells us what to look at, but not yet how to measure it (e.g., "At what point does architecture become 'too complex'?").

The Future of BPO

The future lies in Hybrid Intelligence. We are moving toward systems where the cloud orchestrator automatically triages tasks: simple ones go to the crowd, sensitive ones stay in-house, and complex ones go to specialized experts. This research provides the first few lines of the "playbook" for that hybrid future.

Find Similar Papers

Try Our Examples

  • Find recent empirical studies or frameworks that quantifiably measure "Architecture Complexity" in Cloud-based Business Process-as-a-Service (BPaaS).
  • Which theoretical models initially defined the relationship between "Task Interdependence" and crowdsourcing success, and how has this evolved in industrial BPO settings?
  • Explore current research on "Private Crowdsourcing" models in highly regulated sectors like Energy or Healthcare to mitigate the identified security and management control risks.
Contents
Crowdsourcing in BPO: Strategic Flexibility or Operational Risk?
1. TL;DR
2. Contextual Positioning
3. The Core Challenge: The Flexibility-Scalability Gap
4. Methodology: Bridging Theory and Practice
4.1. The Decision Matrix
5. Deep Dive: The Energy Sector Case Study
5.1. Key Experimental Validation
6. Critical Analysis & Conclusion
6.1. Takeaway
6.2. Limitations
6.3. The Future of BPO