[Extension Proposal] SC-DEX Workforce Extension Proposal

[vasgat]

SC-DEX Workforce Extension Proposal

Status	Proposed
Extension #	NNN (update when applicable)
Author(s)	Vasiliki Gkatziaki ([email protected])
Partner	Wikirate International e.V. ([email protected])
Updated	2024-11-20
Obsoletes	Any prior SC-DEX extension it replaces, if applicable

---

Objective

The primary objective of this extension is to introduce workforce data transparency within supply chains, thereby allowing the stakeholders to gain a comprehensive understanding of the workforce composition, and worker demographics at different locations in the supply chain. This workforce data will complement existing information about locations to enable responsible sourcing, labor rights compliance, and workforce sustainability assessments.

Motivation

• Problem Statement: This extension aims to address the lack of visibility into workforce composition across the supply chain.
• Stakeholders: There is a wide range of stakeholders who stand to benefit from this extension - ranging from supply chain managers, suppliers, auditors, and investors to workers, NGOs.

Stakeholder Benefits

By including metrics related to workforce diversity, stability, and demographics, this extension helps stakeholders manage risks, report responsibly, ensure labor rights compliance, and improve overall supply chain resilience.

Extension Design

This section defines the technical specifications of the extension, including key data attributes and any other requirements. Describe any new data attributes introduced in this extension and how they contribute to the targeted use case.

Example Use Case: Workforce

This extension tracks data around the composition and characteristics of the workforce in locations of the supply chain.

Below is the proposed extension represented in JSON Schema. The schema captures various attributes such as workforce size, demographic breakdown, role distribution, and employment types to provide comprehensive insights into the workforce structure and characteristics.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "WorkforceExtension",
  "type": "object",
  "properties": {
    "number-of-workers": {
      "type": "integer",
      "description": "Total number of workers at the location"
    },
    "number-of-male-workers": {
      "type": "integer",
      "description": "Number of male workers"
    },
    "number-of-female-workers": {
      "type": "integer",
      "description": "Number of female workers"
    },
    "number-of-migrant-workers": {
      "type": "integer",
      "description": "Number of migrant workers"
    },
    "percentage-of-male-workers": {
      "type": "number",
      "description": "Percentage of male workers",
      "minimum": 0,
      "maximum": 100
    },
    "percentage-of-female-workers": {
      "type": "number",
      "description": "Percentage of female workers",
      "minimum": 0,
      "maximum": 100
    },
    "number-of-permanent-workers": {
      "type": "integer",
      "description": "Number of permanent workers"
    },
    "number-of-temporary-workers": {
      "type": "integer",
      "description": "Number of temporary workers"
    },
    "number-of-part-time-workers": {
      "type": "integer",
      "description": "Number of part-time workers"
    },
    "number-of-full-time-workers": {
      "type": "integer",
      "description": "Number of full-time workers"
    },
    "number-of-workers-with-disabilities": {
      "type": "integer",
      "description": "Number of workers with disabilities"
    },
    "average-age-of-workers": {
      "type": "number",
      "description": "Average age of workers"
    },
    "median-age-of-workers": {
      "type": "number",
      "description": "Median age of workers"
    },
    "average-tenure": {
      "type": "number",
      "description": "Average tenure of workers in years"
    },
    "number-of-unionized-workers": {
      "type": "integer",
      "description": "Number of unionized workers"
    },
    "number-of-workers-in-management": {
      "type": "integer",
      "description": "Number of workers in management roles"
    },
    "number-of-workers-in-production": {
      "type": "integer",
      "description": "Number of workers in production roles"
    }
  },
  "required": [
    "number-of-workers"
  ],
  "additionalProperties": true
}

Example:

"workforce": {
      "number-of-workers": 500,
      "number-of-male-workers": 300,
      "number-of-female-workers": 200,
      "number-of-migrant-workers": 50,
      "percentage-of-male-workers": 60,
      "percentage-of-female-workers": 40,
      "number-of-permanent-workers": 400,
      "number-of-temporary-workers": 100,
      "number-of-part-time-workers": 150,
      "number-of-full-time-workers": 350,
      "number-of-workers-with-disabilities": 10,
      "average-age-of-workers": 35.5,
      "median-age-of-workers": 34,
      "average-tenure": 3.2,
      "number-of-unionized-workers": 120,
      "number-of-workers-in-management": 20,
      "number-of-workers-in-production": 480
    }

Alternatives Considered

This is the first proposed SC-DEX extension so there are no any alternatives currently to consider. However, there are some concerns that are expressed on the Questions and Feedback section.

Technical Considerations

Describe relevant technical considerations for implementing this extension. Cover topics like performance (e.g., speed, memory usage), dependencies (e.g., integrations with standards or tools), and compatibility with SC-DEX and other extensions.

Implementation Plan

Complete the following prompts to outline the implementation approach:

• Milestones:

  • Initial steps for designing this extension
  • Steps for validating the extension with stakeholders
  • Final steps for integrating into SC-DEX

• Partner Organizations: A number of partner organizations can be considered as data holders, collectors, or stewards. Some of them are: Clean Clothes Campaign (CCC), Mapped In Bangladesh (MiB), Wage Indicator, Issara Institute, Open Supply Hub, Wikirate, Supply Trace.

• Next Steps:

  • Reach out to partner organizations with a description of the use case and proposed extension.
  • Gather information about their API and/or data-sharing protocols.
  • Explore initial steps to co-create this extension within the SC-DEX ecosystem for exchanging supply chain data.

Questions and Feedback

I am wondering if this workforce extension can be further split into additional, more granular extensions. Are there any logical groupings or divisions you think would make the data more manageable or useful?

For example we could split into workforce-demographics and worker-rights with the latter incorporating additional information such as labor-union, workers-committee, digital-payment, collective-bargaining, permanent-workers, temporary-workers, working-hours, average-tenure etc.

What are your thoughts on this approach? Would these groupings help make the data clearer and easier to use, or do you see other ways we could divide the data more effectively?"

[shuyag]

Love this extension proposal, and noting that this is a location related extension--although potentially also could be an organizational one? Would an organization vs location version of this need to be different?

(Note from @vasgat: locations are more relevant for supply chains data, rather than organizations)

[shuyag]

Related to the data attribute around "average tenure" I could also see one around retention or turnover.

"annual-turnover": {
      "type": "percentage",
      "description": "percentage of new workers every year"
    }

[emilyoxford]

Some additional thoughts:

• Would this be a good spot to include information about wages?
• Could this potentially include time frame information? E.g. "valid_from", "valid_to"

[vasgat]

Some additional thoughts:

• Would this be a good spot to include information about wages?
• Could this potentially include time frame information? E.g. "valid_from", "valid_to"

I think, it comes to the same question, if this workforce extension should be split to several. Personally, I would like to keep things minimal per extension, so ideally I would limit further the number of attributes on the workforce extension and develop another one for related to wages, it could be under worker-rights or another extension that makes more sense.

As to your second point, I do agree. I think, we really need metadata to capture the validity of the data. There has been some discussion around this already here. Maybe, we can discuss it further on a follow-up session.

[siberian1967]

Are we considering data checking rules?

Ex: Male+Female workers must == number of workers etc?

When we do data quality checks on our data, we try to consider things like this. Do extensions here have the concept of internal data validation?

[scrthq]

Seeing that we're using JSON Schema directly here, is the development a meta-schema for extensions like this (e.g. how fiboa handles their extension meta-schema) still being considered?

[philhb]

I have a more general comment which relates to mitigating the potential misuse of this type of extension. Although the core SC-DEX has general utility, this extension is signalling standardised employee aggregate data collection from suppliers, which has complex implications. For example, although data related to this extension could be used for compliance and responsible sourcing, it might also be used for irresponsible sourcing because some indicators could be used as proxies for productivity, overhead costs, etc. (there may also be potential de-anonymization risks - but need to check this).

Given the power dynamics of buyer/supplier, I’d recommend a deeper exploration of the business processes that might use datasets derived from this extension, and involve more suppliers located in the global south as part of this review.

[rendetaylor]

From my position on the ground, working in an organization supporting workers in supply chains and with T1 and upstream suppliers, I second Phil's note of caution -- applying it to workers as well as to the suppliers in the supply chain that have the least power.

It should be noted up front that the wide range of stakeholders identified in the Motivation statement have different and sometimes very conflicting interests regarding workforce data - so what Phil says we can validate is a legit concern from the frontlines - ie what an NGO sees as opportunities to engage and safeguard (eg high numbers of temporary or migrant workers, numbers of unionized workers, etc), a supply chain manager could see as an indicator of risk to cut from their supply chain.

Re workers, when dealing with data from and about workers and/or other vulnerable populations, we would want to see Ethical Considerations alongside any Technical Considerations. Suggest putting an ethics review process with documented findings in place, including people with the appropriate training and a duty of care, to run risk assessments on the different data attributes, grapple with the possible risks to 'Do No Harm,' and explore the business processes that might use datasets derived from the Workforce Extension.

Re Questions and Feedback - Splitting the extension into 2 groups may be a good first step, essentially with one group (say workforce-demographics) including the attributes that more easily pass the ethics / do no harm tests, and then a second group of attributes that require closer review (which look to be most of the others posed above). For now the only attributes that seem "safe" upon initial glance are number of workers, number of workers in production, and breakdowns by gender.

What do others think?

[vasgat]

Are we considering data checking rules?

Ex: Male+Female workers must == number of workers etc?

When we do data quality checks on our data, we try to consider things like this. Do extensions here have the concept of internal data validation?

@siberian1967 JSON Schema allows you to set some rules but for rules that require mathematical calculations things are a bit more complex (use extensions or additional tools). If we want to support data validation of this nature we might need to consider adding custom validation.

Seeing that we're using JSON Schema directly here, is the development a meta-schema for extensions like this (e.g. how fiboa handles their extension meta-schema) still being considered?

@scrthq I had a closer look and I find it really interesting. Do you mean to use something like this for validating the proposed JSON Schema of the extensions?

I have a more general comment which relates to mitigating the potential misuse of this type of extension. Although the core SC-DEX has general utility, this extension is signalling standardised employee aggregate data collection from suppliers, which has complex implications. For example, although data related to this extension could be used for compliance and responsible sourcing, it might also be used for irresponsible sourcing because some indicators could be used as proxies for productivity, overhead costs, etc. (there may also be potential de-anonymization risks - but need to check this).

Given the power dynamics of buyer/supplier, I’d recommend a deeper exploration of the business processes that might use datasets derived from this extension, and involve more suppliers located in the global south as part of this review.

From my position on the ground, working in an organization supporting workers in supply chains and with T1 and upstream suppliers, I second Phil's note of caution -- applying it to workers as well as to the suppliers in the supply chain that have the least power.

It should be noted up front that the wide range of stakeholders identified in the Motivation statement have different and sometimes very conflicting interests regarding workforce data - so what Phil says we can validate is a legit concern from the frontlines - ie what an NGO sees as opportunities to engage and safeguard (eg high numbers of temporary or migrant workers, numbers of unionized workers, etc), a supply chain manager could see as an indicator of risk to cut from their supply chain.

Re workers, when dealing with data from and about workers and/or other vulnerable populations, we would want to see Ethical Considerations alongside any Technical Considerations. Suggest putting an ethics review process with documented findings in place, including people with the appropriate training and a duty of care, to run risk assessments on the different data attributes, grapple with the possible risks to 'Do No Harm,' and explore the business processes that might use datasets derived from the Workforce Extension.

Re Questions and Feedback - Splitting the extension into 2 groups may be a good first step, essentially with one group (say workforce-demographics) including the attributes that more easily pass the ethics / do no harm tests, and then a second group of attributes that require closer review (which look to be most of the others posed above). For now the only attributes that seem "safe" upon initial glance are number of workers, number of workers in production, and breakdowns by gender.

What do others think?

@philhb and @rendetaylor thanks for the feedback you are both raising an important point here and we have to proceed with caution and discuss further. SC-DEX aims to be a data exchange standard that the data is not necessarily going to be publicly shared e.g. the exchange can happen between two or more CSOs with the purpose of deduplicating efforts. However, there is a risk of misuse of the standard that will result in releasing some sensitive data to the public. Some additional ideas to mitigate these risks are:

• Consultations with organizations like Clean Clothes Campaign, Wage Indicator and Mapped In Bangladesh to ensure their concerns around risks on misuse of data are addressed during the development of this extension.
• We can indeed split the original proposal to workforce-demographics and worker-rights. workforce-demographics appears to have less of a risk.
• Incorporate features to flag sensitive data attributes with metadata about usage risks.
• Introduce Usage Guidelines on the documentation of the extension and include a list of potential misuse scenarios.