Global Standards Management Process (GSMP) Manual

1 Introduction

2 What is GSMP?

3 Principles

4 Deliverables: What is developed in GSMP?

5 How GSMP Is Organised – the GSMP Community

6 Direct Participation in Work Groups

7 Work Groups and Governance Groups

8 The 4-Step Process for Creating a GSMP Deliverable

• 8.1 Step 1: Work Requests and Steering



Step 1 of GSMP begins with a GSMP Work Request. Any GS1 member, or Global Office staff in support of the community, may file a Work Request, suggesting a new effort to be initiated in GSMP. A Work Request can ask for something as simple as correcting an error in a published standard to something as complex as creating a completely new GS1 standard or guideline, as well as anything in between.

Work Requests are assessed and approved for development in three stages:

1. The GSMP Operations team reviews the Work Request to confirm that all information needed to assess the entrance criteria has been provided. If not, the Work Request is returned to the submitter to complete. Otherwise, GSMP Operations routes the Work Request to the next stage. Work Requests for simple maintenance or correction of errata in existing GSMP deliverables are routed directly to the responsible SMG without further assessment. Anything else proceeds through the next steps below.

GSMP Operations provide an initial response within 14 days of submission.

2. The Work Request is assessed in the following two areas, collectively called “steering”:

□ Does the Work Request meet or exceed the entrance criteria established for new GSMP work? This includes a commitment to implement from a sufficient number of community members. If not, the Work Request is returned to the requestor.

□ How does the Work Request relate to the entire portfolio of GS1 standards, the GS1 System Architecture, and to other GSMP work already planned or in progress? The GS1 Architecture Group may be consulted at this stage. This assessment leads to a determination of:

- Whether to combine this Work Request with others in the pipeline, and/or split it into multiple efforts

- Which GSMP Work Group should carry out the work: an existing SMG or a new MSWG

- If a new MSWG is called for, the new MSWG’s participation minimums and related SMG

The BCS has decision authority over development work that enters GSMP; however, GSMP Operations carries out a detailed analysis prior to bringing the Work Request to the BCS, including obtaining input from the appropriate GS1 Community Engagement Groups, so that the work of the BCS itself is focused more on approval than on analysis.

3. The GS1 Global Office Leadership Team confirms that the work is consistent with the GS1 Strategy and that the proposed timing of the work is aligned with the available resources. GSMP Operations drafts a Work Group charter (if a new MSWG is to be formed) and the President of GSMP, as a BCS Member, confirms that the charter is consistent with the BCS’s intent.

The BCS and Global Office must provide an initial response within 45 days of the original submission

Because the steering assessment in Step 1 may combine incoming Work Requests that should be handled together and/or split incoming Work Requests that are too large to carry out at once, the Work Requests that proceed through the process are not necessarily in one-to-one correspondence with the original Work Requests. Each Work Request carries links to the relevant original Work Request(s).

• 8.2 Step 2: Requirements Analysis



In Step 2 of the GSMP 4-step process, a Work Group analyses the business requirements that arise from the information provided in the Work Request. The form the requirements analysis takes depends on the scope of the Work Request:

■ For most development efforts to create or revise a GS1 standard, or where the ultimate outputs are uncertain pending requirements analysis, the result of requirements analysis is a Business Requirements Analysis Document (BRAD). Most of the time this is based on the established BRAD template. For certain types of requirements analysis efforts, there may be other recommended tools or intermediate work products to help in the creation of good business requirements, such as use case templates, and so forth.

■ For a Work Request to create a GS1 guideline, some sections of the BRAD template may not apply. The requirements analysis phase should concentrate on documenting all of the use cases that the guideline needs to address.

■ For a Work Request to address errata in a published GS1 standard or guideline, or for extremely narrow maintenance Work Requests, it may be more appropriate simply to document the changes that are needed. For purposes of Step 2, this need not be extremely precise; e.g., it suffices in Step 2 to document a requirement “change all occurrences of ‘Widget’ to ‘Approved Widget’”, rather than document each place in the existing standard where such a change must be made.

■ For maintenance Work Requests pertaining to EDI and GDSN where requirements are periodically consolidated and fed back to GSMP Step 1, the result of requirements analysis may take a highly stylised form, such as a row added to a spreadsheet that will form the basis for the subsequent consolidated Work Request.

Most of the time spent in Step 2 takes place within the “drafting” sub step (2.1). The Work Group begins a draft BRAD or other output as soon as possible, and revise this draft as work progresses over the course of work group meetings.

When the Work Group believes that the BRAD or other output is complete, it proceeds to finalisation, community review, and eBalloting. These sub steps are described in more detail in section 9.

Following the completion of a successful eBallot, the BRAD or other output is now a final document (see section 15). If the Work Group is chartered to both requirements analysis and development, the Work Group proceeds to GSMP Step 3. Otherwise, the Working Group has completed its work. Different requirements may be routed to different work groups, and/or combined with others to be addressed in a single development effort.

• 8.3 Step 3: Development



In Step 3 of the GSMP 4-step process, a Work Group develops a GS1 standard or guideline according to the Work Request, guided by the business requirements that were developed in Step 2. The deliverable may be a completely new GS1 standard or guideline, or it may be a new version of an existing GS1 standard or guideline.

Most of the time spent in Step 3 takes place within the “drafting” sub step (3.1). The Work Group begins a draft standard or guideline or other output as soon as possible, and revises this draft as work progresses over the course of work group meetings. When appropriate, the Work Group may solicit assistance at this stage from GS1 Global Office staff who are assigned to provide specific technical help to Work Groups. Examples include UML modelling, technical writing, and others.

When the Work Group believes that the draft standard, guideline or other output is complete, it proceeds to finalisation, community review, IP review, eBalloting, and ratification. These sub steps are described in more detail in section 9. All of these sub steps, in the figure above, are required.

Depending on the nature of the Work Request, there may be additional sub steps in Step 3:

■ (Sub steps 3.5–3.7) If the Work Request is to develop or revise a GS1 standard for which GS1 offers a conformance certification program, the Work Group also develops a Conformance Requirements document. This document is drafted, finalised, and community reviewed separately from the GS1 standard itself. The Work Group is encouraged to overlap work on the Conformance Requirements document with other work; normally work on the Conformance Requirements document begins when the draft GS1 standard is finalised.

■ (Sub step 3.8) For technical GS1 standards, it is highly encouraged for a Work Group to conduct Prototype Testing following community review of the standard. During Prototype Testing, members of the Work Group each attempt to implement the standard, and compare these efforts with each other to identify potential areas where the standard document may be insufficiently clear or contains errors. As a result, further revisions may be made to the draft standard.

■ (Sub step 3.4) If a Work Group develops conformance requirements, carries out prototype testing, or both, a preliminary IP review may be done in order to uncover IP issues as early as possible, while work on the former tasks is underway. This does not eliminate the need for the final IP review, which the GS1 IP policy requires be initiated 30 days prior to ratification. A preliminary IP review is not necessary if no significant time would elapse between it and the final IP review.

• 8.4 Step 4: Collateral Development



In Step 4 of the GSMP 4-step process, a Work Group develops collateral materials that are used to support deployment of GS1 standards and guidelines by end users, solution providers, and MOs These materials may include any of the following. Note that not all such materials need be created by a GSMP Work Group; in many cases, it will be more appropriate for GS1 Global Office or MO staff to do so. In the collateral planning sub-step (4.1), the Work Group decides which materials it will create.

■ Impact Statement: The Impact Statement describes issues that user companies may face in deploying the new GS1 standard or guideline, particularly as it relates to compatibility, transition, and interaction with other GS1 standards and guidelines. The Impact Statement may also provide some qualitative information as to the size of the effort that is likely required to deploy.

■ Value Proposition: The Value Proposition describes why a user company or solution provider should implement the standard, in business terms that they can take to their budget holders for approval. For example, the Value Proposition might indicate the expected cost to implement and compare it to the expected benefit to the user companies.

■ Implementation/Migration Plans: These documents are intended to answer questions such as: How will end users adopt a new or revised standard and at what pace? Is there a need for coordinated community action? Do two (or more versions) co-exist and what are the sunrise and sunset dates?

■ Training Materials/Support Tools: These are materials intended to help the user understand the key concepts and principles upon which a GS1 standard is built, specific material or exercises to support classroom or online trainings, and online tools that provide simplified access to a given GS1 standard or guideline.

■ Marketing Collateral: Marketing Collateral refers to materials intended to introduce the GS1 standard or guideline to user companies, solution providers, and other community members who may have no prior knowledge of the GS1 standard or guideline or who may not understand to what extent it applies to them. The purpose of Marketing Collateral is to achieve as broad adoption as possible by encouraging community members to examine the new GS1 standard or guideline and determine how it may be of benefit to them. Examples of marketing collateral include:

□ Brief Abstract

□ Frequently Asked Questions

□ Overview Slides

□ Areas of Applicability

After the initial publication of collateral materials, the Work Group may be asked to revise them as necessary.

9 Drafting, Finalisation, Community Review, eBallot

10 Work Group Meetings

11 Work Group Decision Making

12 Appeals

13 Membership Rights and Responsibilities

14 Policies: Competition Law, Code of Conduct, IP

15 Publication of GSMP Deliverables

16 Appendix: Abbreviations

17 Appendix: Group Policies

• 17.1 Group Leadership

Every GSMP group shall include the following designated members:

■ Group Co-Chairs: It is recommended that two or more group voting members share the responsibility for leading the activity of the group. The work group may approve a different number of chairs based on its business need. It is recommended at least one co-chair be present at every group teleconference and physical meeting. A group may also occasionally ask a group member to volunteer to serve as a temporary co-chair for the duration of a scheduled meeting for which all regular co-chairs are unavailable. If there is a vacancy in one co-chair position the group may continue its activity while a replacement is sought according to the process defined in section 18.1.4. It is preferred not to have two or more co-chairs from the same type of Participant Company.

Work Groups should strive to elect co-chairs from different communities within the group (retailers, suppliers, different geographies, etc.). Co-chairs shall be champions of the key GSMP principles (section 3).

The responsibilities of the co-chairs are defined in section 17.1.1, below.

■ Group Facilitator: A GS1 Global Office staff person assigned to handle administrative responsibilities for the group. The facilitator must be present at every group teleconference and physical meeting. A facilitator may designate another GS1 Global Office staff person as a substitute if the facilitator is unavailable to attend a meeting.

The GSMP Group Facilitators are guided by these principles, which remind them of their commitment to the community they serve. GSMP Group Facilitators agree to:

□ Be results driven and take ownership for the effectiveness of meetings

□ Maintain an environment where everyone contributes

□ Inform – Excite – Empower – Involve their community

□ Gain maximum global commitment to the solution

□ Personalise the meeting experience

□ Ensure consistent meeting facilitation across the organisation

The responsibilities of the Group Facilitator are defined in section 17.1.2, below.

■ GS1 Subject Matter Expert (SME): A GS1 Global Office staff person who is familiar with the subject matter of the standard or guideline being developed in the work group, and understands the relationship of the material to the rest of the GS1 system and to GS1’s global strategy. This is especially important in Standards Maintenance Groups (SMGs), where continuity of experience is important.

■ GS1 Architecture Group (AG) Liaison: A GSMP Community Member who also is a member of the GS1 Architecture Group. The AG Liaison opts-in and participates in the Work Group as an ordinary participant. In addition, the AG Liaison brings to the WG broad understanding of all GS1 standards and how they relate to each other and to GS1’s architecture principles. The AG Liaison keeps the GS1 Architecture Group informed of the WG’s progress, and ensures that the AG is aware of any WG activity that may have architectural impact.

Any GSMP group may designate additional leadership roles at the recommendation of the Group co-chairs and be confirmed by a motion of the group. It is common for a standards Work Group to designate a Document Editor in this way to take responsibility for editing the final work product of the Work Group. (The Editor may be the Facilitator, the SME, or any other WG member.) As another example, a Work Group creating a Business Message Standard may have a Modeller assigned from GS1 Global Office staff who prepares the UML and/or GS1 XML schema.

Regardless of leadership positions, all decisions of a GSMP group are made by consensus and confirmed by motions and votes in which all group voting members are equal participants; co-chairs and other designated leadership roles do not have special rights in this regard. GS1 Global Office staff has limited rights in Work Groups; in particular, they may not vote in eBallots or group decisions.

17.1.1 Responsibilities of the Group Co-Chairs

The responsibilities of the co-chairs of any GSMP group are as follows:

■ Ensure that the group fulfils its mission

■ Develop and/or review the agenda for group meetings, in consultation with the Group Facilitator

■ Lead the conducting of business in group meetings

■ Be a champion of the GSMP key principles (section 3) and the GS1 Intellectual Property Policy

■ Work to resolve conflicts that arise during group discussion

■ Make best effort to attend every group meeting (at least one co-chair must be present at every meeting or an alternate elected)

■ Recommend the appointment of additional group leadership positions, subject to confirmation by a motion of the group

■ Represent the group in interactions with other groups, including Governance Groups

■ Ensure that the discussion in meetings accurately reflects group consensus

■ Judge if consensus was reached

17.1.2 Responsibilities of the GSMP Facilitator

GSMP Facilitators bear the overall responsibility for the organisation & management of Work Group calls and meetings within GSMP. Work with the group co-chairs, they facilitate all Work Group activities and additionally are responsible for basic logistics of:

■ Scheduling of calls, face-to-face meetings

■ Meeting Minutes

■ Management of motions and voting

■ Coordination of related Community Rooms

■ Document Management

■ Roster Management GSMP Facilitators also coordinate with Technology SME’s to meet the needs of the user in the Work Groups, informing them of any possible conflicts arising out of standards development against any approved strategy.

■ Specific types of GSMP groups may have additional responsibilities for group facilitators.

■ The key to success for a facilitator is to build a rapport with the community to assure trust, a key enabler to efficiency. Additionally, the facilitator must remain neutral both in action and in appearance.

18 Appendix: Work Group Types and Formation

• 18.1 GSMP Work Groups (WG)

GSMP Work Groups are responsible for carrying out GS1 system development – developing GS1 standards, GS1 guidelines, and collateral materials that support their deployment. Consistent with the principles of openness and community development, all GSMP Work Groups are open to all GSMP members. GSMP Work Groups are the means by which community development takes place.

There are three kinds of GSMP Work Groups:

■ Standards Maintenance Groups (SMG)

■ Mission-Specific Work Groups (MSWG)

■ Work Group sub-team

The decision to address a Work Request (WR) by within an existing SMG or by forming a new MSWG is made during the initial project initiation phase (Step 1 of the GSMP Process), according to established criteria.

18.1.1 Standards Maintenance Groups (SMG)

SMGs have an indefinite lifetime, and are responsible for the ongoing maintenance and enhancement of one or more existing GS1 standards or guidelines. SMGs are intended to provide continuity of expertise, as well as to respond rapidly to requests for small changes. SMGs participate in both requirements analysis and system development (Steps 2 and 3 of the GSMP Process). SMGs also review the work of Mission-Specific Work Groups during community review (IP requirements apply) .

Changes that are handled by SMGs typically include correcting errata, additions to code lists, and other small changes. Errata are defined as changes that do not materially affect the standard or those who have implemented the standard (see section 20.3.3.1 for information on correcting errata).

18.1.1.1 SMG Formation and Termination

The Vice President of Standards Development is responsible for forming and terminating SMGs. A request to form a new SMG must have evidence of community support and a foreseen work stream of maintenance to an existing standard. Examples of situations leading to such a request include:

■ An existing SMG wishes to split into two or more SMGs in order to better accommodate changing scope

■ An existing MSWG finds that it is increasingly asked to handle ongoing maintenance, and so decides it would be better to be re-chartered as an SMG

■ The Vice President of Standards Development decides a new SMG is warranted based on the flow of Work Requests or to better maintain the integrity of a standard

The Vice President of Standards Development considers a request to form a new SMG and is responsible for approving the request. In this process, the Vice President of Standards Development consults with GSMP Operations and relevant community members to consider staffing resources and other constraints.

The Vice President of Standards Development is also responsible for terminating SMGs. Examples of situations leading to the termination of an SMG include:

■ Two or more existing SMGs wish to consolidate into a single SMG

■ An existing SMG determines that its work is finished (e.g., because the standard it was responsible for maintaining has been sunset), or that its remaining work would be better carried out in another SMG or by Mission-Specific Work Groups

■ Or that terminating an SMG is warranted based on the flow of Work Requests

A decision to create or terminate an SMG may be appealed to the Board Committee for Standards.

18.1.2 Mission-Specific Work Groups (MSWG)

The Vice President of Standards Development is responsible for forming and terminating MSWG’s. MSWGs are formed to do a specific piece of work as described in its charter, and which disbands when the work is complete. Mission-Specific Work Groups are created for most work efforts of substantial scope. All Mission Specific Work Groups are approved by the Board Committee for Standards (BCS) before work can begin.

In determining if a body of work requires the creation of an MSWG, the criteria considered includes, but is not limited to, the following: degree of community impact; size of work effort; mix of expertise required; whether the work affects multiple technologies; whether there is a significant change to standards or guidelines or whether the standard is new; and whether the work impacts a new sector or industry. Examples of an MSWG are a new application standard for a sector, creation of a new GS1 ID Key, changing the format of an existing Key and the addition of a new AIDC data carrier/syntax.

Note: A complete list of GSMP Work Groups can be found on the GSMP website at: http://www.gs1.org/standards-development-work-groups.

18.1.3 Sub-Team:

A sub-team of work group members may work in separate meetings specially arranged to progress a work effort and bring that work effort back to the main group. The work effort is approved by an existing GSMP group (ex.: Standards Maintenance Group, Mission Specific Work Group), a sub-team is then created to draft standards changes that are processed by the associated GSMP group. They are ad hoc groups that have no authority to motion or make binding decisions.

18.1.4 Group Chairs

The first order of business for a newly created group shall be to elect co-chairs from among the initial voting membership (excluding Global Office staff). A group shall have two co-chairs, except that the group may designate a different number of chairs based on its business needs. Each co-chair election requires a group eBallot that must meet the minimum participation required by the group; for example: (2-2-2-12) with 2/3 affirmative votes. It is recommended that one co-chair must be from 1 side of the trading partner relationship and the other from a different membership category. Co-chairs shall be champions of the key GSMP principles (section 3) and the GS1 Intellectual Property Policy. For a newly formed group, the call-to-action serves as the solicitation for co-chairs, and co-chairs should be selected prior to the first meeting according to the procedure above. Alternatively, the facilitator may choose to solicit co-chair volunteers during the first meeting if it is not possible to determine them beforehand, again following the procedure above. If there is more than 1 volunteer for a chair position, a group decision is required, a group motion is sufficient if there is only one volunteer. At most one person may volunteer and vote from each organisation. At any time, at most one individual from an organisation may serve as co-chair of a given group.

In an SMG, it is recommended each co-chair serve a one-year term. In a MSWG the term is for the life of the group.

Whenever there is a vacancy in a co-chair seat, the facilitator shall send a notification to the group indicating that one or more co-chair vacancies exist, and solicit voting members to volunteer for the vacant seat or seats. Each vacancy is then filled by a group decision.

Each chair is expected to make his or her best effort to attend every group meeting. If a chair is absent for three or more consecutive meetings, unless the absence was arranged in advance with the knowledge and consent of the group, the group may appeal have the absent chair removed after which the resulting vacancy shall be filled as described above. An individual removed from the chair position in this way may continue to serve as an ordinary member of the group.

The responsibilities of the Group Chairs are described in section 17.1.1.

18.1.5 Work Group Charters

Each Work Group has a Charter that includes the following information:

■ The name of the Work Group

■ A description of the work to be carried out, delineating the scope as precisely and narrowly as possible. For an MSWG, much of this description can be made by reference to a specific Work Request.

■ A description of the kind of organisations that are expected to particularly benefit from participating in this Work Group, or whose membership is especially sought by the Work Group. (It should be noted that Work Group membership is open to all organisations as described in section 6, regardless of what this section of the charter says.)

When the scope of work group changes, the charter must be updated. If changes to the charter are required, they are voted upon by the work group and then sent to the Vice President of Standards Development for approval.

18.1.5.1 Charter Amendment

The Charter Amendment Process allows for existing approved charters to be supplemented. Supplementing an existing charter can be initiated as a result of new, emerging user requirements or new realisations that the scope of the charter be adjusted for business or technical reasons that weren’t envisioned at the time of the original charter’s creation. The reasons for initiating a supplemental charter should be documented and supporting evidence for generating the change should be kept within the record retention area of the impacted Work Group (WG).

All requests for a supplemental charter will be presented to the Vice President of Standards Development for impact and legal assessment.

Once the request is approved, the work group will draft a supplemental charter. The draft shall be approved by WG participants using a Work Group Ballot as specified in section 6.

The amended charter will take effect 30 days (or as dictated by a group decision) after notification to the work group participants that the ballot has carried. There is no requirement to re-opt-in to a WG that is using a supplemental charter (the original WG opt-in is considered to remain in force), though participants can withdraw from the WG if they consider the amendments to be unacceptable.

Additionally, all intellectual property contributed under the original charter now carries over to the supplemental charter and to any standard or technical specification produced under the charter, subject to any IP Declarations previously and properly submitted as per the IP Policy.

A WG may also use the process specified above to reduce the scope of work specified in its charter, including the deliverables, subject to the same approval process specified above.

19 Appendix: Governance Group Members and Responsibilities

• 19.1 Board Committee for Standards (BCS)

The Board Committee for Standards (BCS) is the governing body of GSMP. The GSMP organisation structure includes BCS advisory groups to aid in the leadership and operation of GSMP. Governance Groups are accountable to, and work under the authority of, the BCS.

Note: The following is reprinted from the Board Committee for Standards Internal Regulation. If there is a contradiction, the version in the GS1 Operational Manual will prevail.

The principal responsibilities of the BCS are:

■ Assess that “due process” has occurred in the GSMP

■ Provide operational and strategic policy and guidance in support of the GSMP

■ Oversee the smooth operation of the governance sub-teams of the BCS, namely the GSMP Process and Architecture Groups and advisory groups to the BCS

■ Assess the progress of standards programmes and provide direction on major issues and opportunities

■ Ensure consistent and effective application of the GS1 Intellectual Property policy

■ Review and adapt the ongoing role of GSMP within the changing GS1 strategic landscape

■ Ensure that there is a consistently applied GS1 System Architecture and that all GS1 standards created align with it

■ Make recommendations to the GS1 Management Board (MB) for the ratification of all GS1 standards

■ Oversee all standards created under the GS1 umbrella to ensure that they conform to the principles of the GS1 system and the GS1 Architecture

■ Ensure that GS1 has a standards strategy to deliver world class leading standards within the landscape of new and evolving technologies.

■ Authorise the structures and process that GS1 will use to operate GSMP

■ Regularly monitor GSMP performance to ensure

□ That it is delivering results in line with the GS1 Business Plan

□ Escalations are resolved

□ Correct trade-offs are made between speed and quality of standards

□ Balance occurs between global user priorities and needs of SME and local requirements

■ Ensure that the broad community is aware of and committed to the role of GSMP, its scope, performance and plans

■ Report to the GS1 Management Board (MB)

• 19.2 Ratification

The following outlines the procedure for approving standards (in between Management Board meetings):

1. The Management Board has delegated its authority to approve standards to the BCS.

2. Each Management Board member not present on the BCS may appoint a representative for Standards Approval Oversight

a. For users, this could be the Management Board member or another person.

b. For MOs, this will be the MO CEO Board member

3. Standards are submitted to the BCS and to the Standards Oversight Group (not members of the BCS).

4. The BCS reviews and unanimously approves the standards.

5. Each member of the Oversight Group has 7 days to object to the standards.

a. a. No feedback from the Oversight Group during the 7 days period, shall be considered as ‘no objection’.

b. b. The members of the Standards Oversight Group do not need to vote/support the standard(s). They can only object during the period of 7 days.

6. The Standards are approved if:

a. The BCS unanimously approves the standards

b. There is no member of the Standards Oversight Group objecting to the standards.

7. If the standards are not approved, in line with point 6, the standards will need to be approved by the GS1 Management Board.

19.2.1 Standards Development

Standards Development will proceed with development activities as approved by the Industry Engagement Steering Committee using the Industry Engagement Steering Committee Proposal for Standards Development Work Document and the GS1 1 Year Plan balancing standards related work requests. In cases where this is not possible due to constraints of resource from GS1 or MO/user side and/or skills availability then GSMP Standards Development will advise the BCS and GS1 LT accordingly and offer an alternative work plan based upon availability.

Should the required resources/skills become available then, whenever possible, work should revert back to the original priorities.

For major work efforts a basic assessment of time, effort and skills/resources required to complete should be sought from GSMP Standards Development by the relevant Industry Director/submitter in advance of submission to the BCS.

• 19.3 GS1 Architecture Group (AG)

The GS1 Architecture Group is an advisory body to the BCS and the standards community whose primary responsibility is to develop and document the GS1 System Architecture and, by reference to the architecture, assures the technical integrity, consistency and efficient interoperation of the GS1 system.

The principal responsibilities of the AG are to:

■ Provide review and recommendations for business requirements, standards and services development as required against the GS1 System Architecture and relevant emerging standards developments through the Architecture Review Process.

■ Promote and ensure the continuing relevance of the GS1 system, including its technical integrity and future-proofing.

■ Ensure consistency across the GS1 standards, services, solutions and guidelines.

■ Ensure the GS1 System Architecture is well documented, accessible, extensible, and broadly understood.

■ Ensure that the GS1 System Architecture strives for broad cross-sector applicability but can support the needs of local, regional and sectoral requirements.

■ Ensure the GS1 System Principles and Architecture are fully aligned to GS1 Strategy, Vision, and Mission.

■ Ensure the role of the GS1 Architecture Group and its work items are recognised and understood across the GS1 Community.

■ Advise the GS1 Global Office on liaisons with third party standards organisations.

■ Upon request, respond to issues or questions submitted by members of the GS1 community regarding the GS1 system.

The AG does not change decisions regarding the content of work carried out by GSMP groups; but makes recommendations on matters that affect the technical integrity and interoperability of GS1 system.

The success of the AG is measured by:

■ The delivery of the GS1 System Architecture and clear and consistent architectural principles

■ GS1 system specifications are delivered in a manner that maintains the integrity and interoperability of the GS1 system

■ All “requests for finding” submitted by members of the GS1 community are addressed

19.3.1 Architecture Group Structure

The GS1 Architecture Group comprises technical experts from End User companies, GS1 Member Organisations, Solution Providers, academia and GS1 staff.

The Architecture Group charters sub teams on a mission-specific basis as required to address technical issues related to a particular subject (e.g., EPC, GDSN). Sub teams shall have a defined Charter and scope. Sub teams are disbanded by the Core Team when the Chartered work is complete, unless a business need for continuance is defined.

The AG responsibilities to a Sub-Team are:

■ Initial approval of scope

■ Final recommendations on issues with Architectural Principles and Strategic Issues

■ Guidance and Maintenance of the GS1 Architectural Principles

■ Prompt response to all ‘Requests for Finding’

■ Attendance at sub team Conference Calls or Physical Meetings as needed

■ One AG member to act as Chair

■ Provide a determined membership composition for each sub team

■ Review and approve sub team output

The sub teams are responsible to provide:

■ Expert insight to technical issues related specifically to a particular technology, as such sub team members must have extensive knowledge of the current state of the entity application or topic and technical specifications

■ If the group consists of members from a GSMP work group, add an additional chair from the work group A call for participation to ensure wider representation from the community, if required. The core team determines the balance and representation of each sub team.

Sub team members participate in sub team group decisions to provide recommendations to the Core Team with divergent opinions noted.

19.3.2 Architecture Group Work Method

The AG meets every two weeks provided there are appropriate agenda items, normally by teleconference, but will meet face-to-face as required.

The AG Core Team has a minimum of ten members and a maximum of twenty-five members. The composition of the AG is as follows:

■ Three representatives from GS1 GO Staff (non-voting members)

■ A balanced representation of GS1 Member Organisations (MOs) and of End Users, Solution Providers and academia. To achieve this general balance, the difference between the number of MOs and the sum of the total of End Users plus Solution Providers plus academia shall not exceed two.

The membership of the sub teams should be limited to 12 persons, excluding the AG representatives.

The qualifications of AG members:

■ Members must have extensive knowledge of the overall GS1 system, GS1 standards and guidelines, IT infrastructure/networks, and supply chain

■ Experience in technical system design or architecture design

■ Must have current knowledge of GS1 architecture and input to the system architecture of their own organisation

■ Must be an active participant in the GS1 standards process

■ Prior working knowledge of standards bodies is helpful, but not required

19.3.3 Architecture Group Liaisons to Work Groups

The Architecture Group carries out its responsibilities to review ongoing work within GSMP by participating in Community Review of deliverables and also through active participation in GSMP Work Groups by individual AG members. The latter is formalised in the Architecture Group Liaison process.

The AG designates an AG liaison (AGL) for each GSMP work group. The AGL is a member of the AG and is an active member of the work group in question (subject to the same membership requirements as any other Direct Participant). The AGL:

■ Plays an ambassador role, making the work of AG better known to the WG, with an emphasis on the Architecture and the Architecture Principles;

□ Provides regularly scheduled status reports to the AG so that the AG is kept abreast of progress in all WGs.

□ Plays an advisory role within the WG, communicating their personal view on whether BRADs and Standards drafts are consistent with the GS1 Architecture and comply with GS1 Architecture Principles.

□ When the BRAD and draft standards enter Community Review, the AGL and WG Subject Matter Expert review them against relevant Architecture Principles.

□ When the AGL has a question or concern, they ask WG Chairs for WG Agenda time to discuss.

□ If the AGL question or concern is not satisfied by the WG, the AGL may request an AG Sub-Team be formed (work group IP requirements apply for AG sub team members). The Sub-team would be open to AG and WG members and formal outcomes would be documented in a report

■ All WG deliverables will be made available for AG review at the community review stage. An AG member can request a formal AG review of any particular document.

■ Topics in the AG related to work in progress in GSMP should be limited to issues related to the Architecture Principles.

■ Other comments, related to the ordinary consensus development within a GSMP group, shall be submitted through the normal community review process by individual members of the AG as members of the GSMP group, not as members of the AG.

• 19.4 General Governance Operating Methods

This section outlines operating methods that apply to all the governance groups described above.

19.4.1 General Operating Rules

Governance Groups should maintain a rolling six-month meeting schedule and follow all standard GSMP meeting protocols. Meeting agendas need to be posted to the GS1 Community Room one week in advance. Minutes of meetings are drafted for approval by the Work Group and once approved are posted within two weeks of the meeting.

Decision-making is achieved though consensus, which is defined as approval without sustained opposition. If the team is unable to achieve consensus after all avenues have been explored, then a formal GSMP voting procedure will be invoked. One member equals one vote; invited guests do not vote. In cases when votes are taken the minority view should be conveyed to the BCS together with the majority decision. All group dispute resolutions will be escalated to the BCS.

19.4.2 General Membership Rules

The size of the groups may vary at the discretion of the BCS. Membership composition should, if possible, include GS1 members from all of the GS1 regions (MEMA, North America, Latin America and Asia-Pacific) and sectors, but expertise, leadership and contribution take precedence over regional and sector balance.

Membership eligibility is consistent with GSMP voting membership rules. The membership process begins with a call for nominations. Candidates are reviewed and approved by the BCS.

All members serve a maximum term of three years with staggered terms ensuring continuity and representation (at which time they will need to be re-nominated) except the GS1 standards Executive Representative whose membership remains for as long as he or she is in post. Members may assign a designee in the event they cannot attend a specific meeting. However, the designee has no voting privileges; votes must be cast by the member.

The principal responsibilities of Members are to:

■ Dedicate the necessary time to participate actively and fully in scheduled meetings and conference calls (members must provide a declaration to this effect signed by their line manager)

■ Appropriately prepare prior to meetings, and achieve familiarity with posted meeting materials

■ Follow-up and report on all action items and assignments at and between meetings

■ Participate actively (or have extensive experience) in the standards process

■ Participate actively in the consensus-building process with wisdom and integrity

■ Commit to uphold the GSMP principles including neutrality, transparency and due process

Chairs are chosen in accordance with the GSMP SMG rules and approved by the BCS. The duties of the Chair are to:

■ Call and preside at meetings

■ In conjunction with the facilitator:

□ Approve agendas and organise the meeting program in accordance with the agenda

□ Facilitate the consensus process

□ Assign duties as necessary to advance the work of the group

□ Report to the BCS

□ Ensure the group reaches decisions and conclusions

The duties of the GS1 staff facilitator are consistent with GSMP

■ GS1 will provide a facilitator to each group with no voting rights

The duties of the GS1 standards Executive Representative are to:

■ Implement the group’s decisions

■ Report to the BCS

■ Ensure that the chair has sufficient support from the GO staff

GS1 Intellectual Property (IP) Requirements:

■ Members of all Governance Groups (Core & sub teams) will be required to sign the GS1 Intellectual Property Agreement. AG members must opt-in to work groups in order to perform their duties within the group.

■ Sub team members will be required to sign an Opt-In relevant to topics covered by that work group. Sub team invited guests will also be required to sign relevant Opt-In agreements. A list of relevant topics per Sub team will need to be maintained. It may be decided that Automatic opt-ins are more appropriate, depending on the nature of the Sub team.

Changes to Member Company status:

■ Members who leave their company will receive an email requesting whether or not they wish to continue being a GSMP group member.

■ If the member is employed by a company in membership of an MO and they leave their company but wish to continue to serve, he/she may complete their term provided the new company meets membership criteria and is approved by the BCS. The member will then reapply at end of term as required by all members.

■ If the member is employed by an MO or GS1 Global Office and leaves their organisation, the seat is considered vacant and will be reassigned.

Removal due to Lack of Participation:

■ Members who do not participate in 3 consecutive calls (unless previously discussed with and agreed to by the group) will receive an email requesting whether or not they wish to continue participating.

■ If the participant does not participate in 3 subsequent meetings, another email will be sent requesting that they withdraw from the group.

■ If there is no response to this second email, their names will be removed from the roster of the group and a new member will be appointed to take their place.

■ Members can petition twice to be reinstated via the BCS.

• 19.5 GS1 staff roles in GSMP

This section defines the roles of GS1 Global Office staff in GSMP.

19.5.1 GS1 Leadership Team

The GS1 Global Office Leadership Team (LT) is comprised of GS1 CEO executive staff responsible for creating and managing an environment of skilled and dedicated GSMP staff. The GS1 Leadership Team ensures the execution of the GSMP mission and provides guidance in areas of escalation to the BCS.

19.5.2 GSMP Operations Group

GSMP Operations is a governance support entity which represents the staff function. The mission of GSMP Operations is to ensure effective functioning of the GSMP process by managing its day-to-day operations. It advises the BCS in areas of resourcing and feasibility. It is accountable to the Vice President of Global Standards for its role in the GSMP process.

GSMP Operations monitors and reports progress to the BCS against the Business Plan, assesses proposed changes to the GSMP Manual, shepherds large project proposal documents through the approval process to the BCS and the completion / updating of the Charters for GSMP groups.

The principal responsibilities of GSMP Operations are to:

■ Monitor the process and evaluate performance against the Key Performance Indicators (KPIs) established by the BCS

■ In conjunction with the BCS, develop action plans for process optimisation

■ Ensure large work efforts are approved by the BCS and have a completed Charter which identifies resources, project deliverables, timelines, etc. Direct resource allocation and address issues concerning the capacity of the process

■ Develop, maintain and manage the GSMP infrastructure elements such as the Work Request system and GS1 Community Room, etc.

■ Ensure that stage gate process requirements are met

■ Update all tracking tools appropriately and in a timely manner

The success of GSMP Operations is measured by:

■ Completion of the business plan on time

The GSMP Operations Group meets regularly either by teleconference or face-to-face. Participation in face-to-face meetings and teleconferences is limited to members and invited guests. The group liaises with the BCS on all matters of mutual concern.

The members of the GSMP Operations group are all relevant GS1 staff including the Global Office Standards Development, Solutions and Services and Community Engagement teams.

The responsibilities of the members include:

■ Review and assess all new work requests entered into GSMP

■ Attending scheduled meetings and conference calls

■ Preparing appropriately prior to meetings, including familiarity with posted meeting materials

■ Following-up and reporting on all action items and assignments at and between meetings

■ Participating in the consensus-building process

20 Appendix: Work Request Steering

• 20.1 Work Requests

Work Requests (WR), the entry point into the GSMP process, are submitted to request new standards or modify existing standards. A Work Request is always accompanied by information needed to assess whether it satisfies the entrance criteria for new GSMP work, including evidence that a sufficient number of companies support the effort and intend to adopt the results.

A Work Request defines the scope of a specific work activity to be undertaken by a GSMP Work Group

■ Two or more Work Requests that have similar or overlapping scope may be consolidated into a single (bundled) work item which specifies that the work will address all of the original Work Requests, and includes references to them.

■ A single Work Request that has a large scope may be divided into two or more parts. Each new part specifies a portion of the original Work Request that will be addressed, and includes a reference to the original Work Request.

• 20.2 Work Requests that affect the GS1 keys

GS1 keys are the basis of the GS1 system. If a new or modified GS1 key is proposed, approval is required by the General Assembly.

New GS1 keys or modifications to existing keys should only be introduced to the standard if there are domains of entities for which existing GS1 identifiers are not sufficient for a use case defined in the future by a standards setting group in GSMP.

Creation of a new key means the approval of a new GS1 key which becomes added to the list of existing keys (see the GS1 General Specifications for definition of GS1 key).

Modification to the keys refers to changes to the data definition or format of any of the existing keys. It does not include the use or application of the keys such as the AIDC Application Standard selection of the GS1 keys, GS1 key management standards, assignment of Application Identifier values to keys, or GS1 keys use in GDSN, EDI, EPCIS, EPC Tag Data Standards, etc.

If a new or modification to a key is included in any proposed standard, it becomes a recommendation to the GA via the BCS and MB - electronic approval by the GA may be required.

Refer to the GS1 New Data Carrier Policy for more detailed information on GS1’s Policy on Keys.



20.2.1 Work Requests that affect GS1 Application Identifier (AI) Requests

Any individual or group putting forward a GSMP Work Request for a new or modified GS1 Application Identifier should be aware of the following rules and recommendations around GS1 Application Identifier assignment:

■ Submitted WRs shall not include a request for the exact AI digits to be used (e.g., 888). However, the WR may state whether a 2, 3 or 4 digit AI is requested with justification. If the WR includes the actual values, it will be rejected and the submitter will be asked to resubmit without the values.

■ The GS1 Global Office AIDC Leader shall assign GS1 Application Identifier digits to a Work Group during GSMP Step 3.1, ensuring the AI number will be included in the revised standards during community review and community eBallot.

■ Technical Solution Design & Pilot (Note: these steps are optional and are work request dependent). Any pilot usage or testing of requested AI functionality should be undertaken using 90 series AIs.

20.2.2 GS1 Policy, Principles and Process for the Adoption of New AIDC Data Carriers

Any GSMP Work Request that proposes a new data carrier SHALL be progressed in conformance with GS1 Policy, Principles and Process for the Adoption of New AIDC Data Carriers.

20.2.3 Mandatory review of GS1 standards and guidelines after 3 years

As more standards and guidelines are added to the GS1 system there is a danger that, over time, the system becomes cluttered with unneeded components. This might happen because an individual standard or guideline has:

■ been superseded by a better way to achieve the same function within the GS1 system

■ been added to the system in a decision that, in retrospect, turns out to be wrong

■ never been implemented

Having choices of standards tends to detract from interoperability and unnecessary choices are to be avoided. Therefore, every effort should be made to deprecate and ultimately remove unneeded GS1 system components in support of the principles of interoperability and simplicity. For these reasons each GS1 standards and guidelines that has not been updated in the 3-year period since the original publication date is subject to a mandatory review using the following process.

It is the responsibility of the GS1 Global Office to highlight each GS1 standard or guideline that has not been changed for a 3-year period. Where the standard or guideline is maintained under the responsibility of a Standards Maintenance Groups (SMGs), the responsible Standard Development Leader shall initiate an SMG review that will result in:

■ a recommendation that the GS1 standard or guideline being reaffirmed for a further 3-years (possibly with minor edits, such as refreshed terminology or updated cross-references to other standards)

■ a Work Request for the GS1 standard or guideline to be withdrawn

■ a Work Request for the GS1 standard or guideline to be updated to highlight those sections of the standard or guideline which should be marked for deprecation

For any standard or guideline where there is no SMG responsible for the maintenance, the GSMP Operations Group shall be notified of the mandatory review limit date and make the judgement on the required next step.

• 20.3 GSMP Work Request Processing

20.3.1 Maintenance Work Requests – Assigned to a Standards Maintenance Group (SMG)

When a Work Request relates mainly to the maintenance of an existing standard or guideline, it is typically assigned to a Standards Maintenance Group which is responsible for both requirements analysis and developing the change to the standard or guideline. This is best suited to small maintenance requests for these reasons:

■ The overhead of forming a new work group is avoided, allowing maintenance requests to be handled with greater speed

■ The continuity afforded by a standing group also increases speed, as it is not necessary to bring new members up to speed

■ It is clear at the outset what standard or guideline is affected by the Work Request, so there is no need for the extra step of mapping between requirements efforts and system development efforts

Maintenance Work Requests are handled in one of two ways, as described in the following subsections.

20.3.1.1 Maintenance Work Requests Assigned to a Standards Maintenance Group for Requirements Analysis and System Development

Most Maintenance Work Requests are assigned to a Standards Maintenance Group (SMG) for both Requirements Analysis and System Development. The SMG is responsible for analysing business requirements and documenting them in a Business Requirements Analysis Document (BRAD) or other requirements document. Once the requirements analysis is complete, the same SMG immediately begins work on developing the required changes to the standard or guideline.

20.3.1.2 Maintenance Work Requests Assigned to a Standards Maintenance Group for Requirements Analysis Only, for periodic consolidation

Certain standards, in particular EDI and GSDN standards, are updated on a regular calendar schedule. This is done to allow for a deliberate and planned transition from one version to the next in deployed systems. Work Requests that relate to maintenance of these standards are typically processed using a process flow variation that works in the following manner. The Work Request is assigned to a Standards Maintenance Group (as in section 20.3.1.1), but the Standards Maintenance Group only performs requirements analysis. The results from the requirements analysis phase are then accumulated into a list of pending maintenance changes (typically as a spreadsheet rather than as a collection of BRAD documents). At predefined calendar intervals, these accumulated requirements are then consolidated into a new Work Request.

20.3.2 Development Work Requests – Assigned to a Mission-Specific Work Group

When a Work Request relates to development of new capabilities as opposed to maintenance or extremely small enhancements, a new Mission-Specific Work Group (MSWG) is formed to carry out the work. This allows the appropriate subject matter experts and interested parties from across the GSMP community to become involved and to focus on the single mission.

20.3.3 Decision criteria for GSMP process variations

GSMP Operations, is responsible for ensuring standards are delivered at the speed of business and for determining which process flow variation applies to each Work Request that is initiated in Step 1.

20.3.3.1 Correcting errata

Errata are defined as changes that do not materially affect the standard or those who have implemented the standard (ex. a typo, clarification, or minor change to the document formatting). Though these changes DO require a work request for tracking purposes, they DO NOT require community review or voting for approval. A motion of the SMG responsible for the maintenance of the documentation indicating that no one has concerns with the work request will suffice for errata approval. If there are any concerns with a change classified as errata, the full simple work request process (community review and community eBallot) is required.

20.3.3.2 Maintenance-related vs. Development-related

One dimension on which a Work Request may be described is whether it is maintenance-related or development-related. These are not definite categorisations, and it is foreseen that many work efforts may not readily fit one description or the other. Instead, these descriptions should be viewed as extremes of a spectrum of possibilities. The goal is that Work Requests that are obviously at one extreme or another can be assigned a process flow variation with comparatively little effort during GSMP Step 1, while those lying in the middle will require more thought.

A Work Request lies at the maintenance-related end of the spectrum if it is a small change to an existing standard or guideline that can readily be handled by a standing committee. Examples include: Errata, New EDI code values, new symbol placement rules, GDSN validation rules.

In contrast, a Work Request lies at the development-related end of the spectrum if it involves creation of a new standard/guideline or significant change to existing standard/guideline. Examples include: an extension to GDSN, a new HF air interface standard, an enhancement to the EPCIS standard to include aggregation layers, a new barcode symbology, a new Business Message Standard.

Many Work Requests lie in between these extremes, including maintenance efforts that affect many parts of a standard or more than one standard, and development efforts that are small in scope.

In general, the steering criteria are expected to route Work Requests that are clearly maintenance-related to a Standards Maintenance Group (as in section 20.3.1), and to route Work Requests that are development-related to a Mission-Specific Work Group (as in section 20.3.2). In the middle of the spectrum, the steering process is expected to take into account the specific nature of the Work Request, the known capabilities of the relevant SMG(s), and the potential benefits of expanded and focused participation that can be obtained by chartering a Mission-Specific Work Group. It is expected to err on the side of forming a Mission-Specific Work Group when there is doubt.

Certain small maintenance-related Work Requests apply to standards that are updated on a periodic schedule, principally EDI and GSDN standards. The preferred path for these Work Requests is requirements analysis followed by periodic consolidation (as in section 20.3.1.2 ). Other maintenance-related Work Requests are simply routed to an SMG for both requirements analysis and system development.

21 Appendix: Detailed GSMP process flow

• 21.1 GSMP Step 1: Steering

This section describes the detailed process flow within GSMP Step 1, Steering.



21.1.1 Step 1.1: GSMP Operations Review

Responsible Group: GSMP Operations

Inputs: Work Request submitted by a GS1 member

Process: Any GS1 member or Global Office on behalf of the community, may submit a Work Request using the submission system operated by GS1. The form provided to submitters includes a set of entrance criteria. As part of the submission form, the submitter is prompted to supply information needed to assess the Work Request against those criteria.

The GSMP Operations team reviews the Work Request to confirm that all information needed to assess the entrance criteria has been provided, and then to determine the nature of the work requested:

■ If the information needed to assess the entrance criteria is missing or incomplete, GSMP Operations returns the Work Request to the submitter to complete.

■ Otherwise, GSMP Operations assesses the nature of the work requested:

□ If the Work Request is for simple maintenance or correction of errata in existing GSMP deliverables, the Work Request is routed directly to the responsible SMG as a Work Request approved to proceed with Step 1.6 (in which the SMG reviews the Work Request and moves to begin GSMP Step 2).

□ All other Work Requests proceed to Step 1.2 below.

Criteria for completing this Step: GSMP Operations has completed the assessment described above and selected one of the three possible outcomes for the Work Request.

Outputs: Incomplete Work Request to be returned to the submitter, Work Request routed directly to an SMG, or a Work Request ready for Step 1.2, depending on the decision described above.

It is recommended GSMP operations competes its review within 14 days of the Work Request being submitted.

21.1.2 Step 1.2: BCS Assesses non-Maintenance Work Requests (Conditional)

Conditions: Only performed for Work Requests not routed directly to an SMG in Step 1.1.

Responsible Group: GSMP Operations, with final discussion and approval by the BCS

Inputs: Work Request determined by GSMP Operations in Step 1.1 to be complete and to be something other than simple maintenance. The Board Committee for Standards Project Proposal document for Standards Development. Process: The Work Request is assessed in the following two areas, collectively called “steering”:

■ Does the Work Request meet or exceed the entrance criteria established for new GSMP work? This includes a commitment to implement from a sufficient number of community members. If not, the Work Request is returned to the requestor.

■ How does the Work Request relate to the entire portfolio of GS1 standards, the GS1 System Architecture, and to other GSMP work already planned or in progress? This assessment, described in more detail in section 20, leads to a determination of:

□ Whether to combine this Work Request with others in the pipeline, and/or split it into multiple efforts

□ Which GSMP Work Group should carry out the work: an existing SMG or a new MSWG

□ If a new MSWG is called for, the new MSWG’s participation minimums and its related SMG, and any other GSMP process flow “settings” that will apply to the new MSWG.

To assess the commitment from the community, GSMP Operations may post the Work Request to the GSMP Community to solicit additional statements of support for the work and intention to adopt. This adds to the statements of support already submitted by the Work Request submitter as part of the entrance criteria.

The BCS has decision authority; however, GSMP Operations carries out a detailed analysis prior to bringing the Work Request to the BCS, so that the work of the BCS itself is focused more on approval than on analysis. The BCS takes a more active role for steering decisions that are not routine. Both GSMP Operations and the BCS may consult the GS1 Architecture Group, existing GSMP Work Group co-chairs, GS1 Subject Matter Experts (SMEs), or any other source that may help lead to a better assessment. In all cases, GSMP Operations sends a preliminary analysis to the relevant GS1 Community Engagement groups (sector leadership teams and/or Industry User Groups (IUGs)) for review. Feedback from the GS1 Community Engagement group(s) is included in the final analysis brought to the BCS.

Note: The GS1 Healthcare Leadership Team (HCLT) charter stipulates that the HCLT has the authority to approve any healthcare-only work request (other than maintenance) before it proceeds through GSMP. The BCS must respect the HCLT’s decision for healthcare-only, non-maintenance Work Requests.

It is essential that steering during this step be carried out in an open and transparent manner. The BCS is responsible for approving entrance criteria adopted by GSMP Operations for the triage and prioritisation of Work Requests as defined above and the process by which those criteria are to be applied.

Criteria for Completing this Step:

■ The BCS approves new work for large work efforts.

■ The completed Work Request has been created, including the entrance criteria from the original Work Request(s), the indication of which GSMP Work Group will carry out the Work Request, and all relevant process flow settings for a new MSWG (if applicable). See section 20.3 for the content of a Work Request.

Outputs: Approved standards development project or rejected standards development project.

Exceptions:

■ If the BCS determines that a Work Request does not sufficiently meet the GSMP entrance criteria (despite the earlier review by GSMP Operations) the Work Request is returned to the submitter to rectify and resubmit.

■ The BCS may recommend that commencement of work on the Work Request be delayed to coordinate with the completion of other work or the commencement of other anticipated work, if the BCS judges that will result in an overall better outcome for the community. Such decisions must be explained clearly to the community.

21.1.3 Step 1.3: GO LT Strategy/Resource Check, and Charter Creation (Conditional)

Conditions: Only performed for Work Requests not routed directly to an SMG in Step 1.1.

Responsible Group: GO Leadership Team and GSMP Operations

Inputs: Work Request proposal for the BCS

Process: The GS1 Global Office Leadership Team confirms that the work outlined in the Work Request is consistent with the GS1 Strategy and that the proposed timing of the work is aligned with the available resources.

If in Step 1.2 it was determined that the Work Request is to be carried out by a new Mission-Specific Work Group (MSWG), GSMP Operations drafts a Work Group charter based on the output of Step 1.2, and the President of GSMP, as a BCS Member, confirms that the charter is consistent with the BCS’s intent. See section 18.1.5 for details of the content of a Work Group Charter.

Criteria for completing this Step:

■ The GO Leadership Team has confirmed that the work may begin immediately.

■ A Call-to-Action has been issued, specifying a deadline for sign up of initial members

Outputs: Confirmed Work Request, new MSWG Charter (if applicable)

Exceptions:

■ The GO Leadership Team may postpone commencement of the work if insufficient resources are available to support it at the present time. Such decisions must be explained clearly to the community.

21.1.4 Step 1.4: GSMP Operations Issues Call-to-Action (Conditional)

Conditions: Only performed if a Work Group is new or an existing group requires additional expertise.

Responsible Group: GSMP Operations

Inputs: Work Request and MSWG Charter

Process: The GSMP Operations issues a Call-to-Action derived from the Charter developed in Step 1.3 to solicit membership in the newly formed Mission-Specific Work Group. The Call-to-Action shall include the Work Request including the accompanying information used to assess the entrance criteria. The Call-to-Action shall also specify a deadline for sign up of initial members, after which the first meeting of the Mission Specific Work Group will take place.

Criteria for completing this Step:

■ A Call-to-Action has been issued, specifying a deadline for sign up of initial members

Outputs: Call-to-Action

21.1.5 Step 1.5: Mission-Specific Work Group formed (Conditional)

Conditions: Only performed if a Work Request specifies that work is to be performed by a new Mission-Specific Work Group.

Responsible Group: GSMP Operations

Inputs: Work Request, Call-to-Action

Process: GSMP Operations creates a new Community Room for the Mission-Specific Work Group. A Work Group Facilitator is appointed. The facilitator enters a link to the Work Request and all supporting materials into the Community Room. As participants respond to the Call-to-Action, the GS1 Membership Manager confirms their eligibility to participate (that their organisation has signed the IP Policy and opted-in), and approves their request for group membership. The facilitator keeps track to determine whether the membership minimums established are met. Work Group co-chairs are selected according to the process defined in section 18.1.4.

Criteria for completing this Step:

■ A new Community Room for the Work Group is set up, and the Work Group Charter and supporting materials entered there.

■ A Work Group Facilitator is appointed, and his or her contact information is posted in the Community Room.

■ A sufficient number of eligible initial members respond to the Call-to-Action and are accepted into the team’s Community Room roster, according to the membership minimums established in the Work Group Plan.

■ An announcement of the first Work Group meeting has been sent to the Work Group via the Community Room e-mail function. (The schedule for meetings beyond the first will be established by consensus of the Work Group.)

■ Co-chairs have been selected according to the process defined in section 18.1.4. If an election is necessary, this step completes after the election process is complete.

Outputs: A New Community Room

Exceptions:

■ An insufficient number of members respond to the Call-to-Action, according to the membership minimums established in the Work Group Plan. In this case, Work Group Facilitator shall work with IE to engage additional members, and notify GSMP Operations and the BCS that the initial Call-to-Action failed to gather minimum membership. If this is not successful in meeting the minimums, the BCS is notified, and they decide what to do. The BCS may choose to lower the minimum membership requirements for this Work Group, allowing the group to proceed. Otherwise, the Work Request is terminated for lack of interest. As long as the minimums have not been met, no announcement of initial meeting is sent, and the Work Group does not meet.

■ A sufficient number of volunteers for co-chairs cannot be found. In this case, the Vice President of Standards Development is notified, and decides what to do. No announcement of initial meeting is sent, and the Work Group does not meet. (If co-chair volunteers are solicited during the initial meeting according to section 18.1.4, then no further meetings may be held until the Vice President of Standards Development resolves the co-chair issue.)

21.1.6 Step 1.6: Work Group Reviews Work Request and Moves to Proceed to Step 2

Responsible Group: Work Group

Inputs: Work Request, including information provided with the original Work Requests to support the entrance criteria.

Process: The Work Group Facilitator presents the Work Request and the information provided with the original Work Requests to support the entrance criteria, to the Work Group. The supporting information is now called the Business Case, which the Work Group Facilitator (with assistance from GSMP Operations) will maintain as the Work Group continues its work.

The Work Group reviews the Work Request and Business Case to ensure that it is fully understood by the Work Group. If not fully understood, the Work Group shall seek the assistance of GSMP operations, and if necessary the BCS , to clarify the intent of the Work Request.

When the Work Group is satisfied that it has fully understood the Work Request, it carries out a Group Voice Motion (section 18.1.4 to confirm that the group is are ready to proceed to Step 2.

Criteria for completing this Step:

■ The Work Group is satisfied that it understands the Work Request.

■ The Group Voice Motion to proceed to Step 2 carries.

Outputs: None

Exceptions:

■ If the motion does not carry, the Work Group shall consult the Vice President of Standards Development for assistance.

• 21.2 GSMP Step 2: Requirements Analysis

This section describes the detailed process flow within GSMP Step 2, Requirements Analysis.



21.2.1 Step 2.1: Work Group Performs Requirements Analysis

Responsible Group: Work Group

Inputs: Work Request, including the entrance criteria information submitted with the original Work Request if applicable

Process: The Work Group analyses the business requirements that arise from the stated business need. The form the requirements analysis takes depends on the scope of the Work Request:

■ For most development efforts that are chartered to create or revise a GS1 standard, or where the ultimate outputs are uncertain pending requirements analysis, the result of requirements analysis is a Business Requirements Analysis Document (BRAD). The Work Group shall use the established BRAD template, and work to complete as much of the template as is relevant. For certain types of requirements analysis efforts, there may be other recommended tools or intermediate work products to help in the creation of good business requirements, such as use case templates, and so forth.

■ For a Work Request chartered to create a GS1 guideline, some sections of the BRAD template may not apply. The requirements analysis phase should concentrate on documenting all of the use cases that the guideline needs to address.

■ For a Work Request chartered to address errata in a published GS1 standard or guideline, or for extremely narrow maintenance Work Requests, it may be more appropriate simply to document the changes that are needed. For purposes of Step 2, this need not be extremely precise; e.g., it suffices in Step 2 to document a requirement “change all occurrences of ‘Widget’ to ‘Approved Widget’”, rather than document each place in the existing standard where such a change must be made.

■ For maintenance Work Requests pertaining to EDI and GDSN where requirements are periodically consolidated and fed back to GSMP Step 1, the result of requirements analysis may take a highly stylised form, such as a row added to a spreadsheet that will form the basis for the subsequent consolidated Work Request.

As the Work Group carries out requirements analysis, it should as soon as possible begin a draft BRAD or other output, and revise this draft as work progresses. Orienting the Work Group towards revising a draft deliverable and formulating all Work Group decisions in the form of revisions to the draft helps to keep the Work Group focused on the ultimate goal of producing a document that reflects Work Group consensus. The Work Group co-chairs and Work Group facilitator shall strive to ensure that the draft deliverable reflects the consensus of the group, and to use the group decision making procedures (section 11) to help drive consensus as necessary. Most substantive issues should be addressed before the Work Group proceeds to finalisation of the document in the next step.

Criteria for completing this Step:

■ A clean copy of a “next-to-final” draft BRAD or other requirements document is posted to the Work Group’s Community Room. In most cases, this should take the form of a Word or PDF document with line numbers, to facilitate the finalisation process in the next step.

Outputs: A draft BRAD or other requirements document, ready for finalisation.

21.2.2 Step 2.2: Work Group Finalises Requirements Analysis

Responsible Group: Work Group

Inputs: Draft BRAD or other requirements document

Process: Work Group finalises the BRAD or other requirements document, following the procedure in section 21.5.

Criteria for completing this Step:

■ All Work Group comments collected during finalisation have been addressed by the Work Group, either by making the suggested change to the BRAD or other requirements document or agreeing that no change is required.

■ The Work Group successfully completes a Group Virtual Vote or a Group voice Motion (section 22.1) to approve the completed BRAD or other requirements document. A clean copy of the revised BRAD or other requirements document is posted to the Work Group’s Community Room. This is now a Community Review draft (except in the case of a maintenance Work Request subject to periodic consolidation following section 20.3.1.2, where the output at this stage is not subject to community review).

Outputs: Community Review draft of BRAD or other requirements document (except as noted above)

Termination: In the case of a maintenance Work Request subject to periodic consolidation following section 20.3.1.2, this is the last process step for this Work Request. All other Work Requests proceed to Step 2.3.

21.2.3 Step 2.3: Community Review of Requirements Analysis

Responsible Group: Work Group, with input solicited from AG, any affiliated SMG(s), and the GSMP community

Inputs: Community Review draft of BRAD or other requirements document

Process: Work Group conducts a community review of the Community Review draft BRAD or other requirements document, following the procedure in section 21.6.

During this review, of particular importance are comments received from the GS1 Architecture Group (AG) and any Standards Maintenance Groups to which this Work Group is related. The Work Group shall ensure that comments from those groups are solicited, received, and given special attention during the review process. In particular, any comment received from the AG relating to an inconsistency with the established GS1 architecture and architecture principles must be resolved by the Work Group.

Criteria for completing this Step:

■ All comments collected during the community review have been addressed by the Work Group, either by making the suggested change to the BRAD or other requirements document or agreeing that no change is required.

■ The Work Group successfully completes a Group Voice Motion or a Group Virtual Vote (section 22.1) to commence a community eBallot.

■ The status page of the BRAD or other requirements document is changed to indicate its status as a Candidate Document, and a clean copy is posted to the Work Group’s Community Room.

Outputs: Candidate BRAD or other requirements document

21.2.4 Step 2.4: eBallot of Requirements Analysis

Responsible Group: Work Group, with assistance of GSMP Operations

Inputs: Candidate BRAD or other requirements document

Process: The Candidate BRAD or other requirements document is posted for an eBallot (section 22.2).

Criteria for completing this Step:

■ The Work Group successfully completes a Community eBallot (section 22.2).

■ The BCS is informed of any “no” votes and of all comments that accompany votes received during the Community eBallot.

■ A summary of the vote as described in section 22.2 is posted in an area of the Community Room accessible to the GSMP community.

■ The status page of the BRAD or other requirements document is changed to indicate its status as a Final Document, and a clean copy is posted to the Work Group’s Community Room and to the Community Room accessible to the GSMP community.

Outputs: Final BRAD or other requirements document

Termination: If the Work Request specified that requirements analysis and system development are to be carried out by separate Work Groups (section 20.3.2), then this Work Request terminates. The BRAD or other requirements document, however, will be considered during GSMP Step 2.5, and one or more new Work Requests will be chartered to carry on the system development work. All other Work Requests proceed directly to system development beginning with GSMP Step 3.1.

• 21.3 GSMP Step 3: System Development

This section describes the detailed process flow within GSMP Step 3, System Development.



21.3.1 Step 3.1: Work Group Performs System Development

Responsible Group: Work Group

Inputs: Work Request, BRAD

Process: The Work Group develops a new GS1 standard or guideline, or develops a revised version of an existing GS1 standard or guideline, in accordance with the scope identified in the Work Request. The resulting GS1 standard or guideline shall fulfil the business requirements documented in the BRAD.

As the Work Group carries out system development, it should as soon as possible begin a draft GS1 standard or guideline (if not revising an existing document), and revise this draft as work progresses. Orienting the Work Group towards revising a draft deliverable and formulating all Work Group decisions in the form of revisions to the draft helps to keep the Work Group focused on the ultimate goal of producing a document that reflects Work Group consensus. The Work Group co-chairs and Work Group facilitator shall strive to ensure that the draft deliverable reflects the consensus of the group, and to use the group decision making procedures (section 11) to help drive consensus as necessary. Most substantive issues should be addressed before the Work Group proceeds to finalisation of the document in the next step.

When appropriate, the Work Group may solicit assistance at this stage from GS1 Global Office staff who is assigned to provide specific technical help to Work Groups. Examples include UML modelling, technical writing, and others.

Criteria for completing this Step:

■ A clean copy of a “next-to-final” draft GS1 standard or guideline is posted to the Work Group’s Community Room. In most cases, this should take the form of a Word or PDF document with line numbers, to facilitate the finalisation process in the next step. However, where a standard or guideline is being delivered in HTML, or other online format, a PDF copy with paragraph numbers should be generated from the HTML master to provide an archive version for the Community Room.

Outputs: A draft GS1 standard or guideline, ready for finalisation.

21.3.2 Step 3.2: Work Group Finalises draft GS1 standard or guideline

Responsible Group: Work Group

Inputs: Draft GS1 standard or guideline

Process: Work Group finalises the GS1 standard or guideline following the procedure in section 21.5.

Criteria for completing this Step:

■ All Work Group comments collected during finalisation have been addressed by the Work Group, either by making the suggested change to the GS1 standard or guideline or agreeing that no change is required.

■ The Work Group successfully completes a Group Virtual Vote (section 22.1) to approve the completed GS1 standard or guideline.

■ A clean copy of the revised GS1 standard or guideline document is posted to the Work Group’s Community Room. This is now a Community Review draft.

Outputs: Community Review draft of GS1 standard or guideline

21.3.3 Step 3.3: Community Review of GS1 standard or guideline

Responsible Group: Work Group, with input solicited from AG, any affiliated SMG(s), and the GSMP community

Inputs: Community Review draft of GS1 standard or guideline

Process: Work Group conducts a community review of the Community Review draft GS1 standard or guideline, following the procedure in section 21.6.

During this review, of particular importance are comments received from the GS1 Architecture Group (AG) and any Standards Maintenance Groups to which this Work Group is affiliated. The Work Group shall ensure that comments from those groups are solicited, received, and given special attention during the review process. In particular, any comment received from the AG relating to an inconsistency with the established GS1 architecture and architecture principles must be resolved by the Work Group.

Criteria for completing this Step:

■ All comments collected during the community review have been addressed by the Work Group, either by making the suggested change to the GS1 standard or guideline or agreeing that no change is required.

■ The Work Group successfully completes a Group Voice Motion (section 22.1) to commence a community eBallot.

■ The status page of the draft GS1 standard or guideline is changed to indicate its new status, and a clean copy is posted to the Work Group’s Community Room. The new status is a Prototype Standard, if the Work Plan calls for prototype testing, or a Candidate Standard or Guideline, if not.

Outputs: Prototype GS1 standard, Candidate GS1 standard, Candidate GS1 guideline

21.3.4 Step 3.4: Preliminary IP Review (conditional)

Condition: Only performed if the Work Request specifies that Conformance Requirements are required or if Prototype Testing is called for, and the Work Group determines that these steps will take sufficient time so that an initial IP review is warranted. Otherwise, only the final IP review need be performed. The purpose of the initial IP review is to uncover IP problems earlier in the process, but does not take the place of the final IP review which is mandated by the GS1 IP Policy.

Note: If performed, this step is initiated immediately following the completion of Step 3.3, and runs in parallel with any remaining sub steps within Step 3.

Inputs: Prototype or Candidate GS1 standard or guideline

Process: Work Group facilitator issues a community announcement that the initial IP review for the GS1 standard or guideline has commenced. This announcement shall include the Prototype or Candidate GS1 standard or guideline, shall indicate that this is the initial (not final) review, and that organisations have 30 days to respond using the IP Declaration if they wish to declare IP.

After 30 days have elapsed from the time the announcement is sent, the Work Group facilitator shall gather any received IP Declarations and send them to GS1 Legal Counsel, which shall respond to the Work Group indicating if any action need be taken.

Criteria for completing this Step:

■ An announcement as described above has been sent to the community.

■ 30 days have elapsed since the announcement, and all received IP Declarations forwarded to GS1 Legal Counsel.

■ GS1 Legal Counsel has responded to the Work Group indicating any action that must be taken, such as forming an IP Advisory Group (IPAG) which is an ad hoc group formed to resolve IP issues.

Outputs: none

21.3.5 Step 3.5: Work Group Develops Conformance Requirements (conditional)

Note: The Work Group may perform much of the development work for this step in parallel with Step 3.1, and is encouraged to do so to reduce the total time required.

Condition: Only performed if the Work Request specifies that Conformance Requirements are required; i.e., if there is to be a certification program for the finished GS1 standard.

Responsible Group: Work Group

Inputs: Prototype or Candidate GS1 standard

Process: The Work Group develops a Conformance Requirements Document (section 23.2.7) for the Prototype or Candidate GS1 standard. The Conformance Requirements Document specifies the requirements that a conformance certification test shall meet in order to test an implementation of the GS1 standard for conformance to the standard. The Conformance Requirements Document is used during Step 4 to develop a certification test program. The Conformance Requirements Document is a separate document from the GS1 standard itself.

In the course of developing the Conformance Requirements Document, the Work Group may discover errata to the Prototype GS1 standard. These should be recorded on a comment spreadsheet or using the Community Room comment tracking function, for processing in GSMP Step 3.8.

As the Work Group carries out development, it should as soon as possible begin a draft Conformance Requirements Document (if not revising an existing document), and revise this draft as work progresses. Orienting the Work Group towards revising a draft deliverable and formulating all Work Group decisions in the form of revisions to the draft helps to keep the Work Group focused on the ultimate goal of producing a document that reflects Work Group consensus. The Work Group co-chairs and Work Group facilitator shall strive to ensure that the draft deliverable reflects the consensus of the group, and to use the group decision making procedures (section 11) to help drive consensus as necessary. Most substantive issues should be addressed before the Work Group proceeds to finalisation of the document in the next step.

When appropriate, the Work Group may solicit assistance at this stage from GS1 Global Office staff who is assigned to provide specific technical help to Work Groups.

When the Work Group believes its draft deliverable is complete and reflects consensus, a Group Voice Motion (section 22.1) is used to advance to the step of finalising the document.

Criteria for completing this Step:

■ A clean copy of a “next-to-final” draft Conformance Requirements Document is posted to the Work Group’s Community Room. In most cases, this should take the form of a Word or PDF document with line numbers, to facilitate the finalisation process in the next step. However, where a standard or guideline is being delivered in HTML, or other online format, a PDF copy with paragraph numbers should be generated from the HTML master to provide an archive version for the Community Room.

■ The Work Group successfully completes a group voice motion (section 22.1) to proceed to the next step, finalisation.

Outputs: A “next-to-final” draft Conformance Requirements Document.

Exceptions:

■ If the motion does not carry, the Work Group shall continue to work to drive towards consensus through revisions to the Conformance Requirements Document. If the Work Group feels it has reached an impasse, it may escalate the issue to the Vice President of Standards Development for assistance.

■ If the Work Group determines that development of a Conformance Requirements Document will cause an unacceptably long delay in the ratification of the GS1 standard, the Work Group may appeal to the Vice President of Standards Development to have the development of Conformance Requirements deferred to a separate work effort. In that case, the first version of the GS1 standard will be ratified without Conformance Requirements, and no conformance certification test will be available. At a later time, a Work Request is entered to develop Conformance Requirements and a certification test; this activity is often accompanied by a revision to the GS1 standard itself as errata are typically discovered during the creation of a Conformance Requirements Document. This Work Request proceeds through the GSMP 4-Step Process as does any other Work Request.

21.3.6 Step 3.6: Work Group Finalises Draft Conformance Requirements Document (conditional)

Condition: Only performed if the Work Request specifies that Conformance Requirements are required; i.e., if there is to be a certification program for the finished GS1 standard.

Responsible Group: Work Group

Inputs: “next-to-final” draft Conformance Requirements Document

Process: Work Group finalises the Conformance Requirements Document following the procedure in section 21.5.

In the course of finalising the Conformance Requirements Document, the Work Group may discover errata to the Prototype GS1 standard. These should be recorded on a comment spreadsheet or using the Community Room comment tracking function, for processing in GSMP Step 3.8.

Criteria for completing this Step:

■ All Work Group comments collected during finalisation have been addressed by the Work Group, either by making the suggested change to the Conformance Requirements Document or agreeing that no change is required.

■ The Work Group successfully completes a Group Virtual Vote (section 22.1) to approve the completed Conformance Requirements Document.

■ A clean copy of the revised Conformance Requirements Document is posted to the Work Group’s Community Room. This is now a Community Review draft.

Outputs: Community Review draft of Conformance Requirements Document

21.3.7 Step 3.7: Community Review of Conformance Requirements Document (Conditional)

Condition: Only performed if the Work Request specifies that Conformance Requirements are required; i.e., if there is to be a certification program for the finished GS1 standard.

Responsible Group: Work Group, with input solicited from AG, any affiliated SMG(s), and the GSMP community

Inputs: Community Review draft of Conformance Requirements Document

Process: Work Group conducts a community review of the Community Review draft Conformance Requirements Document, following the procedure in section 21.6.

During this review, of particular importance are comments received from the GS1 Architecture Group (AG) and any Standards Maintenance Groups to which this Work Group is affiliated. The Work Group shall ensure that comments from those groups are solicited, received, and given special attention during the review process.

In the course of processing community review comments for the Conformance Requirements Document, the Work Group may discover errata to the Prototype GS1 standard. These should be recorded on a comment spreadsheet or using the Community Room comment tracking function, for processing in GSMP Step 3.8.

Criteria for completing this Step:

■ All comments collected during the community review have been addressed by the Work Group, either by making the suggested change to the Conformance Requirements Document or agreeing that no change is required.

■ The Work Group successfully completes a Group Voice Motion (section 22.1) to commence a community vote.

■ The Work Group successfully completes a Community eBallot (section 22.2).

■ The BCS is informed of any “no” votes and of all comments that accompany votes received during the Community eBallot.

■ A summary of the vote as described in section 22 is posted in an area of the Community Room accessible to the GSMP community.

■ The status page of the Conformance Requirements Document is changed to indicate new status, and a clean copy is posted to the Work Group’s Community Room and to the Community Room accessible to the GSMP community. The new status is a Candidate Conformance Requirements Document.

Outputs: Candidate GS1 Conformance Requirements Document

21.3.8 Step 3.8: Work Group Performs Prototype Testing of Standard or Guideline (conditional)

Condition: Only performed if the Work Request specifies that prototype testing is to be done

Responsible Group: Work Group

Inputs: Prototype GS1 standard or guideline

Process: The Work Group tests the draft GS1 standard or guideline to ensure that it is implementable. Specifically, the Work Group seeks to ensure that the GS1 standard or guideline is clear, accurate, unambiguous, self-consistent, and complete. No new development or change in scope shall be contemplated at this stage, except as necessary to correct any failure to achieve these properties.

In most cases, the process of prototype testing of a standard or guideline entails Work Group members each individually attempting to implement the standard or guideline, and comparing these efforts with each other to identify potential areas where the standard or guideline document may be insufficiently clear or contains errors. When possible, Work Group members attempt to achieve interoperability of independent implementations as a means to identify such problem areas. If the Work Group finds a disagreement between two implementations, it does not necessarily indicate that the standard or guideline needs revision (it could, for example, simply be an error in one or both implementations). Instead, the Work Group should consider such disagreements to identify a potential place where the standard or guideline needs revision, and then the Work Group must delve deeper to determine what action to take. Any proposed changes should be recorded formally for later review by the Work Group during finalisation.

The Work Group members should attempt to devise a sufficient number of test cases so that all normative statements in the standard or guideline receive some testing at this stage. It may be possible to achieve complete test coverage among a collection of implementations during prototype testing, even if no one of those implementations is a complete implementation of the standard or guideline.

It should be noted that the goal of prototype testing is only to identify and fix errors in the draft standard or guideline that prevent interoperable implementations from being created using the standard or guideline document. Prototype testing is not intended to confirm whether the draft standard or guideline succeeds in meeting business requirements or addressing a business need – the latter is addressed through industry pilots conducted by IE, not prototype testing in GSMP Step 3.8. Prototype testing is also not intended to confirm whether a given implementation conforms to the standard or guideline – the latter is addressed through conformance certification performed after the standard or guideline is ratified. The sole purpose of prototype testing at this step is to ensure the quality of the standard or guideline under development.

When the Work Group believes it has thoroughly tested the draft standard or guideline and has collected all proposed revisions, the working group incorporates those changes into the draft standard or guideline via the process of finalisation (section 21.5). Any changes to the draft standard or guideline arising from the completion of the Conformance Requirements Document are also incorporated at this stage. A Group Virtual Vote (section 22.1) is used to approve the completed GS1 standard or guideline.

Criteria for completing this Step:

■ All proposed changes are captured and ready for finalisation.

■ The Work Group successfully completes a Group Virtual Vote (section 22.1) to approve the completed GS1 standard or guideline. The result is now a Candidate GS1 standard or guideline, and a Candidate Conformance Requirements document (if applicable).

Outputs: Candidate GS1 standard or guideline, Candidate Conformance Requirements document (if applicable).

21.3.9 Step 3.9: Final IP Review

Note: This step must be completed before the GS1 standard or guideline is submitted to the BCS for ratification in Step 3.11.

Inputs: Candidate GS1 standard or guideline

Process: The Work Group facilitator issues a community announcement that the final IP review for the GS1 standard or guideline has commenced. This announcement shall include the Candidate GS1 standard or guideline, shall indicate that this is the final review, and that organisations have 30 days to respond using the IP Declaration if they wish to declare IP.

After 30 days have elapsed from the time the announcement is sent, the Work Group facilitator shall gather any received IP Declarations and send them to GS1 Legal Counsel, which shall respond to the Work Group indicating if any action need be taken. This response shall also be provided to the BCS during ratification.

Criteria for completing this Step:

■ An announcement as described above has been sent to the community.

■ 30 days have elapsed since the announcement, and all received IP Declarations forwarded to GS1 Legal Counsel.

■ GS1 Legal Counsel has responded to the Work Group indicating any action that must be taken, such as forming an IP Advisory Group (IPAG) which is an ad hoc group formed to resolve IP issues.

Outputs: none

21.3.10 Step 3.10: eBallot of GS1 standard or guideline

Responsible Group: Work Group, with assistance of GSMP Operations

Inputs: Candidate GS1 standard or guideline, Candidate Conformance Requirements Document (if applicable)

Process: The Candidate GS1 standard or guideline, along with the Candidate Conformance Requirements Document if applicable, is posted for an eBallot (section 22.2).

Criteria for completing this Step:

■ The Work Group successfully completes a Community eBallot (22.2).

■ The BCS is informed of any “no” votes and of all comments that accompany votes received during the Community eBallot.

■ A summary of the vote as described in section 22.2 is posted in an area of the Community Room accessible to the GSMP community.

■ The status page of the GS1 standard or guideline is changed to indicate its new status, and a clean copy is posted to the Work Group’s Community Room and to the Community Room accessible to the GSMP community. The new status is an Unratified Standard or Guideline, and Unratified Conformance Requirements Document (if applicable).

Outputs: Unratified GS1 standard or guideline, Unratified Conformance Requirements Document (if applicable)

21.3.11 Step 3.11: Ratification by the GS1 Management Board

Responsible Group: GS1 Management Board, with the BCS

Inputs: Unratified GS1 standard or guideline with a summary of “no” votes cast during community eBallot (with their accompanying comments)

Process: The Board Committee for Standards confirms that due process has been followed in creating the Unratified GS1 standard or guideline, as well as the Conformance Requirements Document if applicable, and votes to ratify it (them).

Note: The GS1 Management Board delegates its authority to ratify standards to the BCS on two conditions: 1. The BCS votes unanimously to ratify; and 2. There are no objections from members of the GS1 Management Board who are not represented on the BCS.

Work Requests that affect the GS1 keys will need to be approved by the GS1 General Assembly following ratification. See section 20.2 for information on Work Requests that affect the GS1 keys.

Criteria for completing this Step:

■ The GS1 Management Board ratifies the GS1 standard or guideline, as well as the Conformance Requirements Document if applicable.

■ The GS1 standard or guideline has been approved by the GS1 General Assembly, if the GS1 standard or guideline arises from a Work Request that affects the GS1 keys as defined above.

Outputs: Ratified GS1 standard or guideline; Ratified Conformance Requirements Document (if applicable)

21.3.12 Step 3.12: Publication

Responsible Group: GS1 Publications Staff

Inputs: Ratified GS1 standard or guideline

Process: GS1 Publications Staff publishes the Ratified GS1 standard or guideline.

See section 15 for more details of the publication process.

Criteria for completing this Step:

■ The Ratified GS1 standard or guideline has been published to the GS1 public website.

Outputs: Publication of previous outputs

• 21.4 GSMP Step 4: Collateral



21.4.1 Step 4.1: Work Group Confirms List of Collateral Materials

Responsible Group: Work Group, in collaboration with Community Engagement

Inputs: Work Request, BRAD, Business Case, Ratified GS1 standard or guideline

Process: The Work Group considers what collateral materials ought to be developed in Step 4, and creates a list that documents this decision. The Work Group shall collaborate with Community Engagement to create this list. As a starting point, the Work Group shall consider all of the collateral materials listed in sections 8.4 and 23.3 as possible candidates for inclusion.

When the Work Group agrees it has reached consensus on the list of collateral materials, it confirms this through a Group Voice Motion (section 22.1).

Criteria for completing this Step:

■ A list of collateral materials that has been reviewed with Community Engagement is posted to the Work Group’s Community Room.

■ The Work Group successfully completes a group voice motion (section 22.1) to proceed to the next step.

Outputs: A list of collateral materials.

Exceptions:

■ If the motion does not carry, the Work Group shall continue to work to drive towards consensus through revisions to list of collateral deliverables. If the Work Group feels it has reached an impasse, it may escalate the issue to the Vice President of Standards Development for assistance.

21.4.2 Step 4.2: Work Group Creates Collateral Materials

Responsible Group: Work Group

Inputs: Work Request, BRAD, Business Case, Ratified GS1 standard or guideline, List of Collateral Deliverables.

Process: The Work Group creates collateral materials in accordance with the list developed in Step 4.1.

As the Work Group carries out this step, it should as soon as possible begin a draft document for each deliverable and revise these drafts as work progresses. Orienting the Work Group towards revising draft deliverables and formulating all Work Group decisions in the form of revisions to the drafts helps to keep the Work Group focused on the ultimate goal of producing documents that reflect Work Group consensus. The Work Group co-chairs and Work Group facilitator shall strive to ensure that the draft deliverables reflect the consensus of the group, and to use the group decision making procedures (section 11) to help drive consensus as necessary. Most substantive issues should be addressed before the Work Group proceeds to finalisation of the documents in the next step.

When the Work Group believes its draft deliverables are complete and reflect consensus, a Group Voice Motion (section 22.1) is used to advance to the step of finalising the documents.

Criteria for completing this Step:

■ A clean copy of a “next-to-final” draft of each collateral deliverable is posted to the Work Group’s Community Room. In most cases, each should take the form of a Word or PDF document with line numbers, to facilitate the finalisation process in the next step. However, where a standard or guideline is being delivered in HTML, or other online format, a PDF copy with paragraph numbers should be generated from the HTML master to provide an archive version for the Community Room.

■ The Work Group successfully completes a group voice motion (section 22.1) to proceed to the next step, finalisation.

Outputs: A “next-to-final” draft of each collateral deliverable identified in the List of Collateral Materials

Exceptions:

■ If the motion does not carry, the Work Group shall continue to work to drive towards consensus through revisions to the draft deliverables. If the Work Group feels it has reached an impasse, it may escalate the issue to the Vice President of Standards Development for assistance.

21.4.3 Step 4.3: Work Group Finalises Draft Collateral Deliverables

Responsible Group: Work Group

Inputs: “next-to-final” draft collateral deliverables

Process: Work Group finalises each collateral deliverable following the procedure in section 21.5.

Criteria for completing this Step:

■ All Work Group comments collected during finalisation have been addressed by the Work Group, either by making the suggested change to the deliverable or agreeing that no change is required.

■ The Work Group successfully completes a Group Virtual Vote or Group Voice Motion (section 22.1) to approve the completed collateral deliverables.

■ A clean copy of each collateral document is posted to the Work Group’s Community Room. Each is now a Community Review draft.

Outputs: Community Review draft of collateral deliverables

21.4.4 Step 4.4: Community Review of Collateral Deliverables

Responsible Group: Work Group, with input solicited from AG, any affiliated SMG(s), and the GSMP community

Inputs: Community Review draft of Collateral Deliverables

Process: Work Group conducts a community review of the Community Review drafts of all Collateral Deliverables, following the procedure in section 22.2. The Ratified GS1 standard or guideline shall be pointed out to the community during this review for reference purposes, but it shall be made clear that comments are only solicited for the collateral deliverables, not for the Ratified GS1 standard or guideline. The Ratified GS1 standard or guideline is not subject to further revision at this stage.

During this review, of particular importance are comments received from the GS1 Architecture Group (AG) and any Standards Maintenance Groups to which this Work Group is affiliated. The Work Group shall ensure that comments from those groups are solicited, received, and given special attention during the review process. In particular, any comment received from the AG relating to an inconsistency with the established GS1 architecture and architecture principles must be resolved by the Work Group.

Criteria for completing this Step:

■ All comments collected during the community review have been addressed by the Work Group, either by making the suggested change to the collateral deliverable or agreeing that no change is required.

■ The Work Group successfully completes a Group Voice Motion (section 22.1) to commence a community eBallot if applicable.

■ The BCS is informed of any “no” votes and of all comments that accompany votes received during the Community Review.

■ A summary of the vote as described in section 22.2 is posted in an area of the Community Room accessible to the GSMP community.

■ A clean copy of each revised collateral deliverable is posted to the Work Group’s Community Room, to the Community Room accessible to the GSMP community, and to the public as appropriate.

Outputs: Final collateral deliverable

21.4.5 Step 4.5: Ongoing Revision to Collateral Materials as Needed

Responsible Group: Work Group

Inputs: Approved Collateral Materials

Process: As user companies and solution providers begin to adopt GS1 standards and guidelines, it is sometimes discovered that collateral materials require enhancement. For example, it may be necessary to add additional questions to an FAQ document in order to address questions that have arisen frequently following publication.

The Work Group continues to exist for as long as needed in order to maintain the collateral materials. Only collateral materials may be maintained in this manner; any change to the GS1 standard or guideline itself, no matter how small, requires a new Work Request that begins the GSMP Process at Step 1.

21.4.6 Step 4.6: Development of Conformance Certification Test Plan (conditional)

Condition: Only performed if the Work Request Plan specifies that a conformance certification test is to be developed.

Responsible Group: Conformance Certification Test Organisation as designated by the GS1 Global Office, with support from the Work Group

Inputs: Ratified GS1 standard, Ratified Conformance Test Requirements

Process: The Conformance Certification Test Organisation develops a conformance certification test plan that meets the requirements specified in the Conformance Certification Test. The conformance certification test plan shall specify exactly what artefacts may be tested, and the detailed test plan for testing each kind of artefact. If the conformance test plan includes optional tests, it shall specify clearly what options are available and how they will be indicated in the conformance certification test report created for any given artefact that is tested. The conformance certification test plan is a separate document from the GS1 standard itself.

The Conformance Certification Test Organisation shall work with the Work Group to resolve questions regarding the interpretation of the GS1 standard and the Conformance Requirements document.

Criteria for completing this Step:

■ The Conformance Certification Test Organisation has completed a conformance certification test document and presented it to the Work Group for approval.

Outputs: Draft conformance certification test plan

21.4.7 Step 4.7: Work Group Approves Conformance Certification Test Plan (conditional)

Condition: Only performed if the Work Request Plan specifies that a conformance certification test is to be developed.

Responsible Group: Work Group

Inputs: Draft Conformance Certification Test Plan

Process: The Work Group conducts a Group Virtual Vote (section 22.1) to approve the draft Conformance Certification Test Plan.

Criteria for completing this Step:

■ The Work Group successfully completes a Group Virtual Vote (section 22.1) to approve the draft Conformance Certification Test Plan.

Outputs: Final conformance certification test plan

Exceptions:

■ If the vote does not pass, Steps 4.6 and 4.7 are repeated, during which the Work Group shall work with the Conformance Certification Test Organisation to resolve issues.

• 21.5 Finalisation of a draft document by a Work Group

Several steps of the GSMP 4-Step Process specify that a draft document (such as a draft Business Requirements Analysis Document, draft GS1 standard, etc.) is to be “finalised” by the Work Group. The word “finalised” refers to a specific sequence of steps to be carried out by the Work Group, defined below. The purpose of finalisation is for the Work Group to make final revisions to the draft document in preparation for proceeding to the next stage of the process. The finalisation process gives all members of the Work Group a final opportunity to propose changes to the document before it passes to review by some other body (community review, ratification, etc.).

The process for finalisation is as follows:

■ Finalisation begins after a successful Group Voice Motion to begin finalisation. The Work Group shall agree on the period to be allowed for the submission of comments by Work Group Members: at least one week, but longer if warranted by the size or complexity of the document to be finalised.

■ The Work Group Facilitator (or Work Group Document Editor, if one has been designated), prepares a “next-to-final draft” by accepting all prior changes to produce a fair Word or PDF copy with line numbers. However, where the document is being delivered in HTML, or other online format, a PDF copy with paragraph numbers should be generated from the HTML master to provide an archive version for the Community Room.

■ The Work Group Facilitator posts the draft to the Work Group Community Room. The Work Group Facilitator sends an announcement to the Work Group via the Community Room email function including the draft, instructions for submitting comments (either a comment spreadsheet or the Community Room comment tracking function), and the date and time by which comments are to be submitted.

■ Each Work Group member reviews the draft and records their organisation’s comments following the instructions provided.

■ (Mission-Specific Work Group only) Simultaneous with the Work Group review, a Mission-Specific Work Group shall prepare a summary presentation of the deliverable, and invite members of “related” SMGs who have opted-in to the MSWG to attend an MSWG meeting to receive the presentation. This provides an opportunity for the related SMGs to provide input prior to the completion of finalisation, and also serves to advise the related SMGs that a community review is imminent.

■ Following the close of the review period, the Work Group Facilitator consolidates all comments into a single spreadsheet (if comment spreadsheets are used).

■ The Work Group reviews each comment, and decides how to address it. A comment may be addressed by accepting the proposed change, adopting a different change, or deciding that no change is warranted. In each case, the resolution of a comment shall be decided by consensus of the Work Group (see section 11), and recorded in the spreadsheet or Community Room comment area.

■ After all comments are reviewed, the Work Group Facilitator (or Work Group Document Editor, if one has been designated) edits the draft according to the comment resolutions.

■ The draft is now finalised, and ready for the Work Group to vote to advance to the next stage. The comment resolutions (spreadsheet or Community Room comment function) becomes part of the permanent archive of the Work Group, and serves as a record that due process was followed.

• 21.6 Community Review

Several steps of the GSMP 4-Step Process specify that a draft document (such as a draft Business Requirements Analysis Document, draft GS1 standard, etc.) is to undergo community review and revision by the Work Group. Community Review refers to a specific sequence of steps to be carried out by the Work Group and the GSMP community, as defined below. The community review process gives all voting members of the GSMP community an opportunity to propose changes to the document before it is complete. While Work Group members may also submit comments during community review, it is preferable if Work Group members raise their concerns during the finalisation process that precedes community review.

The process for community review is as follows:

■ Community review begins after the Work Group finalises a Community Review draft and completes a successful Group Virtual Vote or Group Voice Motion to begin community review. The Work Group shall agree on the period to be allowed for the submission of comments by the community: it is recommended to be at least 14 days. It can be shorter or longer as defined by the business needs of the group.

■ The Work Group Facilitator (or Work Group Document Editor, if one has been designated), prepares a Community Review draft to produce a clean Word or PDF copy with line numbers. This document shall be prepared in line with the GS1 Style Guide and clearly marked as a Community Review draft. However, where a standard or guideline is being delivered in HTML, or other online format, a PDF copy with paragraph numbers should be generated from the HTML master to provide an archive version for the Community Room.

■ The Work Group Facilitator posts this draft to the GSMP Community Room that is designated for community reviews. The Work Group Facilitator sends a community announcement using the established community announcement mechanism; this announcement shall indicate that a community review is beginning, and include the draft, instructions for submitting comments (either a comment spreadsheet or the Community Room comment tracking function), the comment submission form, and the date and time by which comments are to be submitted.

■ Any member of the GSMP community may review the Community Review draft. If a community voting member wishes to submit comments on behalf of his or her organisation, he or she may do so following the instructions provided, prior to the close of the review period. If the submitting organisation has not opted-in to the Work Group, the organisation must sign a comment submission form or else their comments shall be rejected by the Work Group Facilitator and not shared with the Work Group. Comments from opted-in organisations do not require a comment submission form (see section 24).

■ Following the close of the review period, the Work Group Facilitator consolidates all comments into a single spreadsheet (if comment spreadsheets are used).

■ The Work Group reviews each comment, and decides how to address it. A comment may be addressed by accepting the proposed change, adopting a different change, or deciding that no change is warranted. In each case, the resolution of a comment shall be decided by consensus of the Work Group (see section 11), and recorded in the spreadsheet or Community Room area.

■ After all comments are reviewed, the Work Group Facilitator (or Work Group Document Editor, if one has been designated) edits the draft according to the comment resolutions.

■ The draft is now complete, and ready for a Community eBallot to advance to the next stage. The comment resolutions (spreadsheet or Community Room comment function) becomes part of the permanent archive of the Work Group, and serves as a record that due process was followed. The comment resolutions shall be posted to the GSMP Community Room that is designated for community reviews, so that all community voting members may review the comment resolutions prior to casting their votes.

■ If the Community Review resulted in no changes to the draft document, the draft document can be submitted directly for Community eBallot.

21.6.1 Community Review Comments by a Standards Maintenance Group (SMG) or the GS1 Architecture Group (AG)

During community review, it is expected that among the reviewing parties will be the GS1 Architecture Group (AG), as well as any affiliated Standards Maintenance Groups. The AG and each affiliated SMG may choose to submit their community review comments in one of two ways:

■ Individual AG and SMG voting members may submit comments as individuals representing their respective organisations, as would any individual responding during community review.

■ The AG or an SMG may choose to submit a single set of comments on behalf of the entire AG or SMG. In this case, the AG or SMG shall ensure that each submitted comment reflects consensus of the entire AG or SMG, using the normal procedures for achieving group consensus. Comments submitted in this way shall be marked as originating from the AG or SMG as a whole rather than as originating from an individual. Note that the process of achieving consensus within the AG or SMG is likely to take time, and so if the AG or SMG chooses to adopt this procedure it must work to ensure it has adequate time to achieve consensus and still submit the comments within the review period established for the community review.

Regardless of how comments are received from the AG and affiliated SMGs, the Work Group receiving the comments is expected to give particular attention to comments from those sources. In particular, any comment received from the AG relating to an inconsistency with the established GS1 architecture and architecture principles must be resolved by the Work Group. Outputs that are believed to be inconsistent with the architecture by the AG should not progress until they are reviewed and resolved by the AG.

22 Appendix: Voting Procedures

• 22.1 Work Group Motion for Ordinary Group Decisions

■ A Work Group Voice Motion is used to confirm group consensus in situations where the participants in a meeting are considered sufficiently representative of the group

□ A Work Group Voice Motion is conducted according to the following procedure: The facilitator or a group co-chair clearly states the issue on the table and identifies the acceptable responses (typically “yes” or “no”). In the case of a yes/no vote, the facilitator may elect to facilitate a decision by asking for a motion for decision and asking if there are any objections. A decision can also be facilitated by asking each attendee to explicitly answer yes or no.

■ A Work Group Electronic Vote can be used to reach all group participants or when it is determined participants in a meeting are not considered sufficiently representative of the group.

□ A Working Group Electronic vote is conducted according to the following procedure: The facilitator or a group co-chair clearly states the issue in an email or electronic motion form, and identifies the acceptable responses (typically yes, no or multiple choice).

□ The facilitator sends an email to Work Group community room email list in which the motion is clearly stated. The Work Group members are asked to respond within seven days if there are any objections to the motion carrying.

□ The final tally shall be recorded in the meeting minutes. A group member may request that “no” votes and abstentions be recorded in the minutes with the name of the organisations so voting.

The motion carries if the following conditions are met; it fails to carry otherwise:

A motion is carried with a simple majority vote or when a 1^st and 2^nd motion is reached, with no objections. In a case of multiple-choice decisions, the choice with the simple majority (i.e. 50% +1) carries the motion. As stated above, abstentions are considered toward meeting voting quorum, but are not part of the calculation of the simple majority. If the motion fails to carry (i.e. to reach simple majority), the group should continue discussions to attempt to reach consensus. The group is encouraged to work towards the broadest consensus rather than push through a matter that only has the bare minimum support required for passage.

• 22.2 Community eBallot

A Community eBallot is used to confirm community consensus following community review, prototype testing (if applicable), and revision of a draft BRAD, standard, or other GSMP deliverable. It marks the transition from one major step of the GSMP 4-Step Process to the next.

A Community eBallot is conducted according to the following procedure:

■ A group co-chair clearly identifies the document draft to be submitted to Community eBallot, and confirms that the group is ready to begin the Community eBallot. If the Community Review results in no changes to the draft document, the draft document can be submitted directly for Community eBallot.

The group establishes a date and time for the close of the Community eBallot. This shall be between 7 and 14 days as determined by the group, from the time the eBallot is announced to the community in Step 4. The group may choose to extend the period; for example, if the 14 days would span a period of expected absence by many community voting members, if the matter at hand is expected to require an extended period for full consideration, or any other reason.

■ As soon as practical, the group facilitator sets up a Community eBallot using the Community Room balloting facility in the area designated for Community eBallots. The eBallot shall clearly identify the draft to be approved, and carefully explain the consequence of a “yes” or “no” vote. The document under consideration and a summary of how each issue submitted during community review was addressed by the Work Group, along with any supporting materials, shall be attached to the eBallot.

■ The group facilitator announces the eBallot to the community using the regular community communications mechanism.

■ Any organisation eligible for Community eBallot may cast one vote. If two or more representatives from the same organisation are members of the community, they must provide a single vote for that organisation. Only MOs, MO Members, and GDSN Certified Data Pools may vote; GO staff, Non-Voting Members, and GO/MO Affiliates may not.

■ While the eBallot is in progress, the details of what organisations have cast votes and what those votes are shall not be revealed to any person except the group facilitator. If any vote is cast with an accompanying comment, however, the text of the comment shall be made available to all members of the community, with the identity of the organisation withheld (unless the organisation chooses to identify itself within the text of its comment).

■ After the closing date and time is reached, a summary is made available to all members of the community that shows which organisations voted, what each organisation’s vote was, any accompanying comments, and a numeric tally of all the votes. This summary shall become a permanent part of the group’s archive alongside the group minutes.

The eBallot carries if the following conditions are met; it fails to carry otherwise:

■ The established voting minimums are met from among the organisations that cast votes; and

■ At least 2/3 of the votes cast are “yes” votes.

■ Abstention votes are deemed as neither supporting nor rejecting the proposal and are considered toward meeting voting quorum, abstentions are not part of the calculation of consensus meaning:

□ A vote of abstain is counted when calculating the voting minimums

□ A vote of abstain is not counted when calculating the 2/3 majority

If an eBallot to recommend a GS1 standard for ratification does not reach the required voting minimums:

If an eBallot to recommend a GS1 standard for ratification does not reach the required voting minimums and a 2/3’s affirmative vote, a second attempt can be made. The second attempt must reach the group’s required voting minimums and a 2/3’s affirmative vote. If the second attempt fails, the vote fails and is returned to the Work Group.

23 Appendix: GSMP Deliverables

• 23.1 Ratified Deliverables

This section defines the deliverables that are ratified by the GS1 Management Board via the BCS. The primary purpose of the GSMP is to create these deliverables. The deliverables in the other sections exist only to support the development and adoption of the ratified deliverables.

23.1.1 GS1 standard and GS1 guideline

A GS1 standard is a specification that ensures interoperability and consistency throughout supply chains. In GS1 terminology, “standards” are normative, meaning that they are prescriptive. Conformance with the standards is required to claim GS1 compliance.

It is important to note the distinction between what is actually a standard vs. a guideline. Efforts sometimes begin as guidelines and evolve during the creation process into standards.

■ It is a standard if (a) it's a document that defines a certain way of doing things, such that two or more companies must do what the document says in order to achieve some common goal; or (b) it's a document that defines a certain way of doing things, such that it will be difficult to change later.

■ If neither of the above are true, and furthermore the document explains a way of doing something that is consistent with existing standards, then it is a guideline.

GS1 standards and guidelines are further explained by the following text, quoted from the GS1 System Architecture:

There are four types of artefacts that make up the GS1 system:

■ GS1 standards: A GS1 standard is a specification that defines the behaviour of one or more system components so that certain goals are achieved. Typically these goals are interoperability of system components, whether different components deployed by the same supply chain party or components deployed by different supply chain parties. Standards contain normative statements, which specify what a system component must be or do in order to be in conformance to the standard; a standard is written in such a way that conformance to the normative statements is a sufficient condition for a system component to achieve the interoperability or other goals for which the standard is designed.

■ GS1 guidelines: A GS1 guideline is a document that provides information considered useful in implementing one or more GS1 standards. A GS1 guideline never provides additional normative content beyond the standards to which it refers; instead, the purpose of a GS1 guideline is to provide additional explanation and suggestions for successful implementation. While conformance to a GS1 standard may be necessary to achieve an interoperability goal, use of a GS1 guideline is never required. GS1 standards typically focus on “what” a system component is or must do, whereas GS1 guidelines may provide additional suggestions for “how” such a component may be implemented. GS1 guidelines may be general in nature (applying to all implementations) or may be specific to a limited number of use cases or industries.

GS1 standards may be further distinguished according to the type of normative content they contain, as follows:

■ Technical Standards A technical standard is one that defines a particular set of behaviours for a system component. Technical standards focus on “what” a system component must be or do to be in conformance to the standard. Technical standards are typically written to be as broadly applicable across business sectors and geographic regions as possible. While a technical standard may illustrate specific business problems to which it applies, a technical standard does not specify which industries or businesses must adopt the standard. An end user may choose for itself whether to deploy a component that conforms to a particular technical standard.

Technical standards may be further distinguished as follows:

□ Data Standard A data standard is one that defines the syntax and semantics of data. Conformance to a data standard is assessed by examining a particular instance or instances of data to see whether it follows the normative statements laid out in the data standard.

□ Interface Standard An interface standard is one that defines an interaction between system components, often by defining the syntax and semantics of messages that are exchanged between system components. Conformance to an interface standard is assessed by examining a particular system component (often a hardware or software product) to see whether it correctly generates messages and/or responds to received messages according to the normative statements in the interface standard. Most interface standards identify two roles as the interacting “sides” of the interface and a given system component is assessed for conformance to one or the other of these roles (or sometimes both).

The distinction between data and interface standard is not always sharp, and many technical standards contain both data specifications and interface specifications. Indeed, because data is always exchanged across an interface, an interface standard nearly always contains a data standard or refers normatively to other data standards.

■ Application Standards An application standard is one that specifies a particular set of technical standards to which end user systems must conform in a particular business application. Application standards provide a convenient way for different end users to express their agreement to follow certain standards, in order to achieve mutually agreed interoperability goals in a given application context.

Application Standards are examples of profiles, a profile being a standard whose normative content consists exclusively of references to other standards along with normative constraints upon their use. Application Standards take the form of a profile together with statements about the application area to which it applies. A profile may also be a technical standard that defines a subset of one or more other standards for a narrower purpose.

In general, GS1 standards seek to specify a single way of achieving a given business goal. In some cases, GS1 standards provide alternatives; for example, a standard that defines two different concrete syntaxes for the same abstract data construct, each optimised for a different implementation context. Having choices detracts from interoperability, and so GS1 standards offer choices of this kind only when absolutely necessary. In some cases, GS1 Technical Standards offer choices and GS1 Application Standards define single choices to be used in different application contexts.

23.1.2 GS1 solutions

GS1 solutions describes a way to navigate a series of choices of GS1 standards, Services, or Guidelines that integrate together to meet a business or technical need. (“Business need” is to be interpreted in the broadest sense to include processes in, for example, healthcare, defines, education etc.). Solutions are non-normative but rely upon normative standards. Solutions do not impose any additional normative statements beyond what is already implied in the standards upon which they are based.

■ Examples: GS1 solution(s) for Traceability, GS1 solution (s) for Patient Safety, or Solution Providers (suppliers of hardware, software, systems integration, consultancy, etc.) are expected and encouraged to design their product offerings on the basis of published GS1 solutions.

23.1.3 GS1 service

A GS1 service is a facility provided by GS1 Global Office (GO) that provides benefit or assistance to parties other than GS1 Member Organisations (MOs).

GS1 service offerings may or may not be based on GS1 standards. Examples:

■ The Global Registry is a GS1 computer service offering based on a GS1 standard.

■ GEPIR is a GS1 computer service offering that is not based on a GS1 standard.

Some GS1 standards define the interface for services; not all such services, however, are “GS1 services.” To illustrate:

■ A service may be offered by the GS1 GO. Such a service is a “GS1 service.”

Example: The ONS standard defines an interface for looking up a service reference for an EPC; a portion of this standard is implemented by the ONS Root, which is a GS1 service

■ A service may be offered by a GS1 MO. Such services are not “GS1 services,” though they are services in the general sense of the word. GS1 Global Services are provided by GS1 GO and GS1 Local Services are provided by MOs.

Example: The EPCIS standard defines an interface by which one supply chain party may make physical visibility event data available to other supply chain parties. Some GS1 MOs have provided EPCIS for the local market.

■ Services offered by parties other than GS1. Such services are not “GS1 services,” though they are “services” in the general sense of the word.

Example: The EPCIS standard defines an interface by which one supply chain party may make physical visibility event data available to other supply chain parties. The party offering this service is a supply chain party (end user), not GS1 GO, and so this is not a GS1 service, despite being governed by a GS1 standard.

23.1.4 GS1 Methodology

A GS1 Methodology is a “meta” standard that provides rules and restrictions for authoring/designing other content standards. These types of standards are used to enforce the principles of consistency, quality, reusability, precision and non-ambiguity into the standards.

Examples:

■ GS1 XML Naming and Design Rules

■ IETF RFC 2119 "Key words for use in RFCs to Indicate Requirement Levels"

■ ISO/IEC Directives “Rules for the structure and drafting of International Standards”

■ UN/CEFACT Core Components Technical Specification (CCTS)

■ “Contributors Credit Policy for EPCglobal Standards”

■ "Use of URIs in EPCglobal Specifications”

■ "Naming Conventions for the EPCglobal Permanent Document Repository”

23.1.5 GS1 Policies vs. Standards

GS1 Policies are the rules for standards development, ensuring alignment of the standards to the broader mission of GS1. Policies are maintained in this manual and the GS1 Operational Manual. GS1 standards and guidelines, in contrast, are contained in the ratified GS1 standard and guideline documents.

Process:

■ The GSMP is the global process established by GS1 for the development and maintenance of global standards and guidelines, which are part of the GS1 system.

■ The GS1 CEO is responsible to propose changes to policies relative to GS1. These changes are proposed to the governance bodies, the General Assembly (GA) and the GS1 Management Board (MB) via the GS1 Board Committee for Standards (BCS).

23.1.5.1 Global vs. Context Specific (e.g. Regional) Standards

GS1 standards are built upon the business requirements of our users within the Global Standards Management Process (GSMP) to meet particular business needs with a truly global solution. These standards are based upon:

■ A single set of methodologies

■ Components in the GS1 Global Data Dictionary (GDD)

■ Rules in the GS1 General Specifications

Within the GSMP, the creation of globally applicable standards takes precedence over a solution for a specific context (region, industry, business process, etc.). While the GS1 standards support regional business practices and help to enable them, the intent is to provide a solution that is applicable in multiple regions and industries around the world. Regional syntaxes are not supported by GSMP.

The determination of a business requirement’s context including whether or not its applicability is regional or global is made during the requirements analysis. In many cases, national regulations and environmental considerations make requirements and the optional solutions they warrant specific to a context, but only if a more broadly applicable solution cannot be created. The local applicability of the requirement is stated in the BRAD.

Business requirements result in the creation of a GS1 standard or a process standard that is based upon global and sometimes context specific components. To improve implementation, the GSMP Work Group may assign a context to a solution using the approved context values and rules of application.

• 23.2 Intermediate Deliverables

This section defines deliverables that are created at intermediate steps within the GSMP 4-Step Process, and exist to support the creation of the ratified deliverables.

23.2.1 Work Request (WR)

The Work Request (WR) is used to describe and track a work effort within GSMP. A Work Request is a proposal for work to be done in GSMP that has not yet been initiated; a Work Request is accepted when it is assigned to a GSMP Work Group. All work carried out in GSMP is governed by a Work Request. See section 20.1 for a complete description.

23.2.2 Business Case

The Business Case is a short document that describes the motivation for producing a GSMP Deliverable (a new GS1 standard or guideline, or modification to an existing GS1 standard or guideline). When a Work Request is approved in GSMP Step 1, the Business Case is created by GSMP Operations by extracting information from the corresponding Work Request(s), specifically the information in the Work Request that was used to assess the entrance criteria. As the Work Request moves through Steps 2, 3, and 4 of the process, the GS1 Facilitator and/or GSMP Operations updates the Business Case to reflect what is learned as the Work Group progresses through the process. When the deliverable is finally published, so is the revised Business Case, thus providing a permanent record for the motivation behind that deliverable.

23.2.3 Call-to-Action

A standard Call-to-Action is used to form a Work Group. The announcement is sent to the GSMP Community and specific target audiences and communicates who should be involved in the project, provides focus on the scope of work, recommends a solution, shows known participants, and provides access to meeting details.

23.2.4 Business Requirements Analysis Document (BRAD)

A Business Requirements Analysis Document (BRAD) is a document that defines the requirements that a GS1 standard or guideline must meet in order to address the business need defined in the Work Request. The BRAD is created by a GSMP Work Group during Step 2 of the GSMP 4-Step Process. The focus of a BRAD is to define requirements that a solution must meet, not to define the solution itself.

23.2.5 Map of Requirements to Standard or Guideline

A GSMP Work Group that creates a GS1 standard or guideline in Step 3 of the GSMP 4-Step Process is also required to create in Step 3 a document that shows how each requirement specified in the BRAD or other requirements document is met by the GS1 standard or guideline. The requirements map may take the form of a table that enumerates each requirement specified in the BRAD or other requirements document, and indicates the section(s) of the GS1 standard or guideline that address the requirement, with explanation as needed. For GS1 XML messages the requirements map may take the BRAD requirements number and associate them with a solution in the schema following the current methodology for XML based GSMP solutions. This is done in a Delta document.

23.2.6 Step 3 Impact Assessment

A new GS1 standard or guideline, and especially the revision of an existing GS1 standard or guideline, may have an impact on user companies. For example, there may be backward-compatibility issues in migrating from and older version to a newer version of a standard, there may be issues concerned with the co-existence of two versions of the same standard, a new standard may have interactions with other already-deployed standards. It is important that these issues be understood before a new or revised GS1 standard or guideline is finalised, so that the new standard or guideline may address them to the extent possible. For example, if a revised GS1 standard has a potential back-compatibility problem, it may be possible to craft the revision in a way that mitigates or eliminates the problem.

For this reason, a GSMP Work Group that creates a GS1 standard or guideline in Step 3 of the GSMP 4-Step Process is also required to create in Step 3 a document that describes the impact of the new GS1 standard or guideline on user companies, with particular attention paid to issues of compatibility, transition, and interaction with other standards. At Step 3, the purpose of the document is to ensure that such issues are considered in the creation of the GS1 standard or guideline; at Step 4 this document becomes input to creating an Impact Statement that is part of the collateral deliverables.

23.2.7 Conformance Requirements Document

If a GS1 standard is subject to a conformance certification program, a Conformance Requirements document is created in Step 3 of the GSMP 4-Step Process by the GSMP Work Group that creates the GS1 standard. The Conformance Requirements Document specifies the requirements for the certification test; that is, it specifies what has to be tested in order to confirm that an implementation under test conforms to the GS1 standard. An important part of the Conformance Requirements Document is defining exactly what constitutes an “implementation under test” for this GS1 standard.

The Conformance Requirements Document is used as input to the process of creating a conformance certification test plan; the latter is created by GS1 or an organisation to which it delegates responsibility, with support and approval from the GSMP Work Group.

In addition to conformance requirements, interoperability requirements will be defined as part of a work plan where applicable, e.g. EPC HW, UHF and HF tags and printers with labels.

• 23.3 Collateral Deliverables

This section defines deliverables that support the deployment by community members of a ratified deliverable. Collateral Deliverables are made available to GS1 Member Organisations and to the GS1 community as a whole to accompany a ratified GS1 standard or guideline.

All Collateral Deliverables are created by a GSMP Work Group in Step 4 of the GSMP 4-Step Process, with assistance from GS1 staff as necessary. Only those collateral deliverables specified in the Work Plan are created for a given Work Request.

23.3.1 Impact Statement

The Impact Statement describes issues that user companies may face in deploying the new GS1 standard or guideline, particularly as it relates to compatibility, transition, and interaction with other GS1 standards and guidelines. The Impact Statement may also provide some qualitative information as to the size of the effort that is likely required to deploy.

The Impact Assessment completed in GSMP Step 3 is the primary source material used in creating the Impact Statement.

23.3.2 Value Proposition

The Value Proposition describes why a user company or solution provider should implement the standard, in business terms that they can take to their budget holders for approval. For example, the Value Proposition might indicate the expected cost to implement and compare it to the expected benefit to the user companies.

The Business Case first created in GSMP Step 1 and revised through subsequent GSMP steps is the primary source material used in developing the expected benefits side of the Value Proposition.

23.3.3 Implementation/Migration Plans

If the ratified deliverable from a work effort is an update or new version of an existing GS1 standard or guideline, migration planning guidance will be needed. How are existing users supposed to move from existing standards to the new and at what pace? Is there a need for coordinated community action? Do two (or more versions) co-exist and what are the sunrise and sunset dates?

If the ratified deliverable from a work effort is an entirely new GS1 standard or guideline, implementation guidance will be needed. How are users expected to carry out their initial adoption of the standard and at what pace? Is there a need for coordinated community action? Is there a defined sunrise date? Is there any relationship to existing standards, and if so, what is the impact on implementations of the existing standard due to adoption of the new standard?

If the ratified deliverable is a new or revised GS1 service, or if the ratified deliverable is a GS1 standard or guideline that interacts with a GS1 service, the Implementation/Migration Plans also describe how user companies’ activity will be coordinated with the activity of GS1 in deploying or upgrading the relevant GS1 service(s).

23.3.4 Marketing Collateral

Marketing Collateral refers to materials (produced by GS1 GO Marketing) that are intended to introduce the GS1 standard or guideline to user companies, solution providers, and other community members who may have no prior knowledge of the GS1 standard or guideline or who may not understand to what extent it applies to them. The purpose of Marketing Collateral is to achieve as broad adoption as possible by encouraging community members to examine the new GS1 standard or guideline and determine how it may be of benefit to them.

Marketing Collateral may include:

■ Brief Abstract: A brief description of the new GS1 standard or guideline that conveys what it is, what problem it solves, who might benefit, and why they should consider adopting. It should be only a few sentences in length. The Value Proposition is a primary input in creating the Brief Abstract.

■ Frequently Asked Questions: A document that provides an explanation of the GS1 standard or guideline and how it is to be used in an accessible question-and-answer format. When possible, an FAQ should be based on actual questions that frequently arose during development of the GS1 standard or guideline.

Note that GS1 and its Member Organisations may create additional FAQs on topics of general interest to the community, but that is not what is referred to here.

■ Overview Slides: A document in slide (e.g., PowerPoint) format that provides an introduction to the GS1 standard or guideline for community members and others who have no prior knowledge. The Overview Slides may draw upon all of the other collateral deliverables for source material, especially the Value Proposition, the Impact Statement, and the introductory material of the GS1 standard or guideline itself.

■ Areas of Applicability: An enumeration of specific business needs that may be addressed by the GS1 standard or guideline. The areas of applicability identified in marketing collateral are not limited to the ones identified in the Business Case – there may be many areas to which a standard applies beyond the ones which happened to instigate the development of the standard or guideline.

■ GS1 Strategy: Documentation of how the new GS1 standard or guideline advances one or more goals of the overall GS1 Strategy.

23.3.5 Outreach Plan

The Outreach Plan defines the specific activities that will be undertaken to communicate awareness of the new GS1 standard or guideline to the community, following ratification. The Outreach Plan may include the following ingredients:

■ Webinars

■ Press releases

■ Marketing Collateral

■ Newsletters

■ Bulletins

■ Announcements sent to email distribution lists

24 Appendix: Piloting of GS1 standards and guidelines

• 24.1 Opting-In to a Work Group

An organisation that has joined GSMP and signed the IP Policy may opt in to a specific Work Group (Standards Maintenance Group or Mission-Specific Work Group) in one of two ways:

■ Explicit Opt-in: An organisation may opt in to a specific Work Group by signing an Explicit Opt-In agreement for that working group. Doing so does not affect the organisation’s status with respect to any other Work Group.

■ Automatic Opt-in: An organisation may sign an Automatic Opt-in Agreement. Upon doing so, the organisation’s representatives may join all current and future GSMP groups (unless the organisation has opted out of a specific GSMP group). An organisation that has signed the Automatic Opt-in Agreement may opt out of an individual Work Group at any time. For a newly created group, the automatic Opt-In takes effect when the Work Group has its first meeting; therefore, an organisation that has signed the automatic Opt-In but does not wish to be opted-in to a newly announced Work Group may opt-out between the call-to-action and the first Work Group meeting, and thereby avoid any IP obligations for that Work Group.

An organisation’s representative that has joined a GSMP Work Group is given access to that Group’s Community Room, which in turn gives access to all work-in-progress of that Group. An organisation that has not opted in to a Work Group does not have access to the Work Group’s Community Room, nor may it attend Work Group meetings. The organisation may still participate in community review and eBallot voting (if voting member) of deliverables produced by the Work Group.

• 24.2 Opting-out of a Work Group

An organisation that has opted-in to a Work Group, whether by Explicit Opt-In or Automatic Opt-In, may opt out at any time. There are two ways to opt-out:

■ Explicit Opt-Out: An organisation may opt out of a specific Work Group to which it had previously opted in, whether by Explicit Opt-In or Automatic Opt-In.

■ Cancellation of Automatic Opt-in: An organisation that previously signed the Automatic Opt-in Agreement may cancel its Automatic Opt-In. The organisation is immediately opted out from all Work Groups except those explicitly designated by the organisation as those for which it wishes to remain opted in, by signing individual Opt-Ins for those groups. The organisation will not be automatically opted in to any new Work Groups created subsequently.

After an organisation has opted out of a Work Group, it no longer has access to the Community Room, and it is also removed from the Work Group roster and associated tools if it had previously joined the Work Group. The organisation may still participate in community review and eBallot voting (if voting member) of Work Group deliverables in the same manner as other organisations that are not opted in.

25 Appendix: Policy for Acknowledging Contributors

26 Appendix: GS1 Competition Law Caution

27 Appendix: GSMP Participation Requirements, Code of Conduct, Conflict Management Rules and Suspension of a Participant

• 27.1 Participation Requirements

It is GS1’s role to protect its community of users and their efforts and investments to the best of its ability. Group or meeting defined participation requirements will be enforced. All participants must comply with the call or meeting participation requirements, as well as the GS1 Competition Law Caution, and sign the Intellectual Property Policy (if applicable, sign Invited Expert form (if applicable) and sign the relevant Opt-In Agreements. If a call or meeting attendee is not in compliance with the call or meeting participation requirements, the GS1 Competition Law Caution or with the Intellectual Property Policy, they will be asked to leave the call or meeting. If they refuse to leave a call or meeting, the session will be terminated and rescheduled.

• 27.2 GSMP Code of Conduct

■ Be Considerate: The decisions made when creating standards will affect many user companies, all points of view are needed to make the right decisions. Please allow all participants to provide their points of view. Once a participant has explained their point of view, however, they should refrain from repeating it numerous times.

■ Be Respectful: Members of GSMP are to treat one another with respect. Disagreement is no excuse for poor behaviour and poor manners. We cannot allow personal attacks or behaviours that make people feel uncomfortable or threatened.

■ If disagreeing, constructively disagree: It is important that we resolve disagreements and differing views constructively and respectfully.

■ Be Collaborative: Collaboration reduces redundancy and improves the quality of our work; we should always be open to collaboration. Our work should be done transparently and should involve as many interested parties from as many business and regional perspectives as early in the process as possible.

■ Be Representative: a speaker should not make remarks which further a personal agenda and are not representative of that speaker’s constituency unless it is clearly stated that the comments are personal. A speaker should not give the impression that they speak for a company or region if they have not spent adequate time clearly explaining the business case to the user company/s they represent and documenting their response. Speaker’s votes should accurately reflect their constituent’s responses. This aligns GS1 with their mission to create user driven standards.

The following subjects may cause offense and are not acceptable, however intended:

■ Disruptive behaviour (e.g., shouting, cursing, derogatory comments, or intoxication)

■ Filibuster (one person talking too loudly or too long to overcome other opinion)

■ Remarks about people (race, religion, ethnicity, gender, age, national identity, national language, nation of origin, sexuality)

■ Disparaging remarks about companies, types of companies or industries

■ The promotion or attempt to sell a particular company, proprietary product or product type, implicitly or explicitly

■ Remarks about another company’s business practices when they are not represented at the meeting

If a discussion leads to any of the preceding behaviours, conflict management rules will be applied.

• 27.3 Conflict Management Rules

■ Before further discussion begins, the Meeting facilitator:

□ Clarifies the objective for the discussion

□ Places a time limit on the discussion

□ Asks all who wish to speak to give their names

□ Divides the time equally or seeks advice from the Chair on whether discussion should be deferred or extended based on interest and other agenda topics

■ Once discussion begins, the Meeting facilitator:

□ Monitors time for each speaker and tells them when their time is up

□ If the speaker does not stop within a reasonable period per the discretion of the Meeting facilitator, the meeting facilitator gives them a verbal warning

□ If after a warning, the speaker does not immediately stop, the Meeting facilitator will suspend the call or physical meeting for one-minute. During this minute, the session is temporarily adjourned.

□ After one minute, the Meeting facilitator will reconvene the session, but if the speaker continues, the session will be stopped, adjourned. The speaker’s organisation will be contacted by GSMP Management to ensure future compliance with GSMP Code of Conduct.

■ Conflict Management Rules are applied:

□ By the Meeting facilitator after ensuring all participants are familiar with the rules

□ Per the Meeting facilitator’s discretion or upon request by any member

□ As a “formal” GSMP intervention process designed to reintroduce a formal structure into GSMP discussions

• 27.4 Suspension or Removal of a Participant

In case of repeated or egregious disregard for

■ the call or meeting participation requirements,

■ the GS1 Competition Law Caution,

■ the Intellectual Property Policy, and/or

■ the Code of Conduct,

GS1 reserves the right to suspend or remove a participant.

The authority to suspend or remove a participant is exercised:

■ by the VP Standards and GS1 General Counsel, in case of suspension or removal from a single group;

■ by the President & CEO of GS1 Global Office, in case of suspension or removal from all GS1 work groups.

The request for suspension or removal may be made by a Facilitator or by at least four participants in the work group, by email notice addressed to the VP Standards and GS1 General Counsel explaining the grounds for suspension or removal of the participant.

The VP Standards and GS1 General Counsel may, in support of their decision or of the decision to be taken by the President & CEO, investigate the matter, seek advice from outside legal counsel and take any conservatory measure they deem fit to avoid any damage to GS1 or to third parties.

The VP Standards and GS1 General Counsel or the President and CEO, respectively, shall not be bound by the request to suspend or remove and may decide to reject the request, or follow up on it and suspend (temporary measure), remove (permanent measure) as well as set any conditions for reinstatement. A suspension or removal will encompass participation in all forms, including meetings, email, Community Room, GitHub posting, etc.

The BCS shall be informed of the request and the decision. The decision shall be notified by email to the participant.

28 Appendix: GSMP Process Evolution

Change log