ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State

Moving forward together, to better serve your business ©2009 GS11

ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To

Be” State

2 September 2009


Outline

• GSMP Principles [Team 1]• Participation• General Policies

• Group Leadership• Anti-trust Caution, Code of Conduct• IP Policy• Teleconferences and Physical Meetings• Consensus / Decision Making• Voting Procedures• Appeals• Loss of Participation Rights and Reinstatement• Access to Work in Progress and Confidentiality

• Organization• Working Groups

Standards Maintenance Groups (SMG) Mission-specific Working Groups

• Governance Groups Central Operations (COPS) Process Oversight Committee (POC) GS1 Architecture Group (GAG) Board Committee for Standards (BCS)

• Process Flow• Community Interaction• Infrastructure


Outline





• Governance Groups Central Operations (POC) POC GAG BCS



Participation

• Participating Organizations and Individuals• Participants in GSMP are organizations (companies, etc)

• Any number of individuals from an organization may participate; however

• Each organization gets one vote, and is counted once for purposes of establishing group participation minimums, etc


Participation

• All work in GSMP is carried out in GSMP Groups

• Working Group• Group responsible for carrying out the system development work of GSMP, including development of

GS1 Standards, Guidelines etc.

• Any organization may join (subject to IP and other pre-requisites)

• Includes: Standards Maintenance Groups (SMG) – standing Mission-Specific Working Group (MSWG) – exists ‘til work done, further classified:

– Combined Development Group (CDG) – requirements and standards (for narrower and/or less technical efforts)

– Requirements Development Group (RDG) – requirements only– Standards Development Group (SDG) – standards only

• Governance Group• Group responsible for ensuring that GSMP process is correctly executed and providing advice

• Does not define standards, guidelines, etc.

• Limited membership, by appointment or election

• Includes: Central Operations (COPS) Process Oversight Committee (POC) GS1 Architecture Group (GAG) Board Committee for Standards (BCS)


Participation

Working Group Governance Group

Group Role Carry out the system development work of GSMP

Ensure that the GSMP process is correctly executedPrioritize work effortsResolve conflictsAdvise Working Groups

Number of Members Unlimited, subject to established minimums

Fixed (possibly subject to small variations)

Membership Open to any participating organization that meets established criteria

By appointment or election

Number of Groups Existing Varies through established process for forming and disbanding Working Groups

Fixed by the enumeration of Governance Groups in the manual

Relationship of an individual, his/her organization, and the group

An individual represents the interests of his/her organization in a Working Group, though should take broader community interests into account whenever possible

An individual represents the interests of the community in a Governance Group, informed by experiences within his/her own organization and the broader community of stakeholders of which his/her organization is a part


Categorization of Participating Organizations

• By relationship to GS1:• GO (staff), MO (staff), MO member in good standing (the most common

case), GO Affiliate, MO Affiliate

• By elective status w.r.t. a specific Working Group:• WG Member

• Opted-in to WG but not a WG member

• GSMP Member but not opted-in to WG

• MO Expert Group Member

• MO LCN Member

• Other (subscriber to MO, but not in above categories)

• By supply chain role:• End user (further subdivided: retailer, mfr, etc)

• Solution provider (further subdivided: hw, sw, etc)

• Auto-ID Labs

• Other SDO


Categorization and Participation

• By relationship to GS1:• MO and MO Member fully participate in GSMP

• GO, GO Affiliate, MO Affiliate may participate in meetings but do not vote

• By elective status:• See chart on next slide

• By supply chain role:• Roles are considered when establishing group minimums; e.g., WG

typically requires 2 end users (from each side of trading relationship), 2 MOs, 2 solution providers.

• Roles do not limit ability to participate and vote: all MO Members may participate and vote regardless of supply chain role (including solution providers)


Elective Status and Participation

Access to community room / Work-in-Progress

Participates in community review

Votes following community review

IP Declarations Solicited

1. WG members Yes Yes Yes Yes

2. Opted-in Yes Yes Yes Yes

3. GSMP member but not opted-in

No access Y, but must sign declaration if comments are submitted

Yes Yes

4. MO expert group member

No direct access, but MO may share materials with Experts under agreement

No direct participation, but MO may present consolidated comment son behalf

No, but MO’s vote may take expert group’s opinion into account

Yes

5. LCN member No access (but LCN has access to an LCN folder)

No direct participation, but MO may conduct LCN survey with liaison

No, but MO’s vote may take LCN’s opinion into account

Yes

6. Other subscriber

No access No No No


Outline





• Governance Groups Central Operations (COPS) POC GAG BCS



Group Leadership

• All GSMP groups have the following designated roles:• Group co-chairs

Two or more At least one present at each meeting Group may continue while a vacancy is being filled

• Group facilitator A GO staff person Must be present at each meeting (but may designate a

substitute)

• All group decisions are by consensus; co-chairs participate with other members equally in this regard


Anti-Trust Caution and Code of Conduct

• All participation subject to GS1 Anti-Trust Caution and Code of Conduct• TBD for Team 4: name of “Anti-Trust Caution” – concern that

the term “anti-trust” is US-specific

• Both are read at start of every meeting


IP Policy

• IP Policy Agreement• Organization must sign in order to join GSMP

• Provisions only operative upon “opt in” to a specific WG

• Opt-In• Obligates organization to IP Policy w.r.t. output of a WG, in exchange

for the right to participate and access WIP

• See next slide for opt-in methods

• Comment submission form• Used in community review for comments from organizations not

opted-in

• IP Declaration• Used during IP declaration period to declare intention not to license

necessary claims on a royalty free basis

Subject to Team 4 Review


IP Policy: Opt in and opt out

• Explicit opt-in:• Organization signs an explicit agreement for each WG to which it

opts in

• Automatic opt-in:• Organization signs automatic opt-in agreement, which opts it in to all

WGs existing at that time, and automatically opts in to any new WG formed with no further action required

• Explicit opt-out:• Organization explicitly opts out of previously opted in WG

• Can do this to exclude certain WGs after automatic opt-in

• Cancellation of automatic opt-in:• Cancels all existing opt-ins

• Must explicitly opt-in thereafter



Meeting Rules (Teleconference and Physical Meeting)

• Written agenda distributed via community room in advance• Calendar invites sent as soon as date is known• Written agenda distributed at least 3 days in advance of weekly meeting or 1

week in advance of less frequent meeting• Minutes taken

• Includes: name & org of all attendees, record of business transacted sufficient for non-attendees to keep up

• Distributed to WG via community room afterward (facilitator decides whether to also issue an e-mail notification)

• Preferably posted before next meeting, but within two weeks in any case• All attending organizations must be WG members and opted in• Participation minimums met.

• Meeting may continue below minimums,• …but no voice votes may be taken• Continued failure to meet minimums escalated to POC by facilitator; POC

may also notify IE• Group encouraged to use community room e-mail to carry on discussion

between meetings


Decision Methods

• Group consensus is overriding principle.• Four methods used:

Decision Type When Used Decision Method

Ordinary Working Decision

This is what a Working Group does in the normal course of developing work products.

Most ordinary working decisions are achieved through informal consensus during Working Group meetings (voice affirmation, or “any opposed?”) Escalate to virtual vote if needed (which supplements votes already tallied by voice)

Process-mandated Voice Motion

Decision to begin formal WG review prior to community review

Voice vote subject to participation minimums. Escalate to virtual vote if needed.

Process-mandated Working Group Virtual Vote

Decision to advance to community review or to ratification(Exception: on “accumulated” path, requirements work ends with a voice motion)

Virtual vote using community room. 7 day duration. Only WG members participate.

Community Virtual Vote (following Community Review)

Completion of work product following community review and addressing of comments.

Virtual vote using community room. 14 day duration. Participation includes all GSMP members (must have signed IP policy).


Voting Details

• Process-mandated voice motions:• Are subject to participation minimums

• If not met, use group virtual vote instead

• Group virtual vote:• Before vote closes, do not reveal voting tallies; only reveal

comments that accompany votes, without disclosing who submitted them.

• After vote closes, disclose the name of each company that voted and what its vote was (along with any comments submitted)

• Community virtual vote:• Same notes as for group virtual vote


Appeals

• Appeals of due process• Aggrieved organization first appeals to group co-chairs and facilitator• If not satisfied, then to POC (BCS also notified that POC appeal is in progress)• If not satisfied, then to BCS• BCS decision is final

• Appeals of Voting Result• If a voting organization believes that the outcome of any particular vote has been unduly

influenced by one stakeholder group, and has thereby resulted in a non-optimal outcome, they can escalate this concern by appealing the vote to the group co-chairs and facilitator

• If not satisfied, then to POC (BCS and industry director also notified that POC appeal is in progress)

• If not satisfied, then to the BCS• BCS decision is final• Automatic appeal of community vote to POC under specified conditions (next slide)• Continuation of process suspended until appeals resolved

• Appeals of Architecture Questions• A group may seek architectural clarification from the GAG• If not satisfied, may appeal to BCS• BCS decision is final


Automatic Appeal of Community Vote

• If an identifiable stakeholder group (e.g. supply side, demand side, 3PLS, MO, SP) participates in a community vote with the following conditions:• A predominance of the stakeholder group did not participate

in the group via opt-in; and

• The stakeholder group’s voting was uniform and divergent from the predominance of the other stakeholder groups; and

• The result of the overall vote would be different in absence of the stakeholder group in question

• …then the vote is automatically appealed to the POC to determine if undue influence was present and remedial action is necessary.


Loss of Participation Rights and Reinstatement

• An organization may lose right to participate in group meetings and vote if:• Continued anti-trust violation after being advised of violation• Continued code of conduct violation after being advised of violation• Unauthorized disclosure of WG materials

• Process:• Co-chairs and POC discuss with organization (the individual, as well as the

organization’s primary contact if different)• If decision is to suspend rights, all WG facilitators are notified, and

organization told what it must do to regain rights• Organization may appeal to BCS, whose decision is final

• Reinstatement:• Organization demonstrates to POC that reinstatement criteria are met• If POC decides to reinstate, all WG facilitators are notified and organization

regains rights• If POC decides against, organization may appeal to BCS, whose decision is

final



Access to Work in Progress and Confidentiality

• WG Members and opted-in organizations have full access to community room, including:• Documents (final and work in progress, minutes, etc)

• E-mail archive

• WG calendar

• WG roster

• An organization may not share above material with any organization that is not a WG member or opted-in, except by permission of GS1 legal

• Exceptions:• All GSMP members have access to documents that have been submitted for community

review

• MOs may share materials with expert group members, under agreement

• All ratified standards, guidelines, etc, are available to the general public on the GS1 website in the Knowledge Center.

• Notwithstanding the above, all GSMP members will have visibility into what work efforts are underway and what is their status with respect to the process flow.



Outline








Organization

• All work in GSMP is carried out in GSMP Groups

• Working Group• Group responsible for carrying out the system development work of GSMP, including development of

GS1 Standards, Guidelines etc.

• Any organization may join (subject to IP and other pre-requisites)

• Includes: Standards Maintenance Groups (SMG) – standing Mission-Specific Working Group (MSWG) – exists ‘til work done, further classified:

– Combined Development Group (CDG) – requirements and standards (for narrower and/or less technical efforts)

– Requirements Development Group (RDG) – requirements only– Standards Development Group (SDG) – standards only

• Governance Group• Group responsible for ensuring that GSMP process is correctly executed and providing advice

• Does not define standards, guidelines, etc.

• Limited membership, by appointment or election

• Includes: Central Operations (COPS) Process Oversight Committee (POC) GS1 Architecture Group (GAG) Board Committee for Standards (BCS)

TBD: Specific groups that exist are TBD pending “committee landscape” discussion


Relationship of Mission-Specific Working Groups to Standards Maintenance Groups

• Mission-specific group is typically related to one or more identified SMGs• In some cases, for example a mission-specific group working on a brand new

area of standards, there may be no related SMGs; this is expected to be rare. In many such cases, the mission-specific group may become an SMG once it completes an initial standard, if justified by ongoing community interest.

• The participation/voting minimums for the mission-specific group include at least two members of each related SMG. (The same people may also be the ones who meet the other minimums.)

• A member of each related SMG is identified as either a co-chair of the mission-specific WG, or, if that is not possible, as a designated liaison member of the mission-specific WG to the SMG

• During finalization, the mission-specific Working Group gives a presentation of the work to the related SMG(s), and encourages the SMG members' participation in the upcoming community review

• SMG(s) is part of community review, and the vote thereafter


Outline








System Development Process per OE 3a

1 Statement of Business Need

2 Requirements Development

3 GS1 System Development

4 Deployment

Clear Definition Of Need

Ratified Standards, Guideline, Approved Solutions, Services

Publications, Marketing, Support Tools and Training

Requirements

Document


Graphics

Do Something = An activity performed by a group

Doc = A document or other deliverable. An output of one activity, the inputto another

5 = An open issue identified in the Team 2 issues list (issue 5 in this example)


ISDP “To Be” – 50,000 foot view

WorkRequest

ISDP 1b:

process initiation

Charter

ISDP 2: require-ments

BRAD

ISDP 3: stan-dards

UnratifiedStandard

ISDP 4: deploy-ment

Like old GSMP “change request” or EPC “enhancement request”

Includes:-Work request(s)-Resource needs-WG assignment (new or standing)-WG chairs (if new)-Settings for ISDP “knobs”-Expected timeline

SBN

ISDP 1a: stmt of need

SBN

Primarily IE Primarily SD

Statement of Business Need, similar to old GSMP Business Case Document

Standard


Handling of Parallel Work Streams

• Many-to-many mapping of Work Requests to Chartered work efforts:• Related work requests may be combined into a single work effort

• One work request may best be split into multiple work efforts

• Variety in the BRAD-to-Standard transition:• “Narrow” path possible when impact of BRAD on standards is clearly

identifiable before BRAD work begins (corresponds to GSMP “simple” process)

• “Accumulated” path used when finished BRADs are accumulated over time then consolidated into a single work effort (as in GDSN)

• Normal path provides for many-to-many mapping of BRADs to standards developments:

Related BRADs may result in a consolidated change to a standard One BRAD may result in parallel changes to several standards Allows decision of which standard(s) are affected to be made in context

of fully documented requirements


ISDP “To Be” – 40,000 foot view

WR

WR

WR

PCD

DraftCharter

DraftCharter

DraftCharter

Work Work

Work

Work

BRAD

BRAD

BRAD

Work Std

Std

Std

PCD

Work

Work

ISDP 1: stmt of need ISDP 2: require-ments

ISDP 3: stds

Work Std

“Accumulated” BRAD path

“Narrow” BRAD path

= Prioritize, Consolidate, DistributePCD

Work = Work done by a WG, including approvals, voting, ratification, etc (detailed in later slides)

5

DevCharter

Work

Work

DevCharter

DevCharter

34

Charter, SBN

Charter, SBN

Charter, SBN

Work

Work

SBN

SBN

WRPCD

WR

If SBN needed

Primarily IE Primarily SD


Charter Ingredients

• Every ISDP work effort is governed by a charter, which specifies

• Title of work effort• References the Work Request(s) to be addressed• Specifies GS1 resources needed• What WG is responsible (standing, or new mission-specific)• WG chairs (for a mission-specific WG)• Settings for ISDP “knobs” (see next slide)• Expected timeline, expressed in terms of ISDP milestones


ISDP “knobs” specified in Charter

• Work Group:• Standing “Standards Maintenance Group” (SMG) (specify which one) –

requires justification against established criteria• New mission-specific group (specify a name for it, and to which SMG, if any,

it reports)• Stakeholder participation minimums

• Identify specific types of end user, solution provider, if appropriate• Provide justification if default minimums are to be waived/altered

• BRAD-to-Standards transition:• Normal path (hand off to standards WG via PCD process)• “Narrow” path (same WG continues from requirements development to

standards development) – must specify which standard(s) will be affected• “Accumulated” path (stops at finished BRAD; at specified trigger such BRADs

are consolidated and entered as a new Work Order)• “Narrow” and “Accumulated” path require justification against established

criteria• Prototype testing: yes or no• Conformance requirements: yes or no• Collateral deliverables needed: implementation plan, impact analysis,

other collateral

6

6

Development charter items


Setting of Process “knobs”

• It is role of IE and POC (with assistance from COPS) to determine the appropriate process “knob” settings for each work effort.• IE/POC responsible for establishing and maintaining criteria

by which these decisions are made

• Starting point for these criteria are given on next few slides

• Charter for work effort records these decisions


GSMP Work Order Spectrum

• Maintenance-Related Order:• 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

• Development-Related Order:• The creation of a new standard/guideline or significant change to

existing standard/guideline.

• A standards or guidelines change that spans topic areas of GS1 Standards

• Examples include: GDSN Extension, HF standard, EPCIS enhancement for layers, New Bar Code symbology, new XML Message

Maintenance-related Development-related


Maintenance-Related Versus Development-Related Orders

• These terms are intended to give broad awareness of the nature of work in a given group. They do not represent explicit categorizations and it is foreseen that many work efforts may not readily fall into one category or another.

• Work efforts obviously at one extreme or the other will be dealt with through “preset” GSMP process settings

• Work efforts that are not obviously one or the other will be dealt with procedurally in the GSMP by an analysis to find the optimal way to address the specific work effort which will be captured in the group Charter and approved by the POC


Spectrum for Standards & Guidelines Content

• Application-Related Standards/Guidelines• GS1 Standards/guidelines that primarily deal with new combinations

of business content with existing business-context neutral technologies

• Examples include: new Business Message Standards (XML) based on existing design patterns, GDSN Extensions (Hardlines, Books, etc.), Traceability Process Standard

• Technology-Related Standards/Guidelines• GS1 Standards defining data, messages, and interfaces that are

business context-neutral (primarily reusable across many business processes), along with GS1 Guidelines for their use

• Examples include: XML “SBDH” (Standard Business Document Header), Certificate Profile, Air Interface Protocols

Application-Related Technology-Related


Application-Related vs Technology-Related Standards / Guidelines

• The terms Application-related and Technology-related are intended for general awareness of the TYPE of user expertise needed to bring about the optimal standard design.

• These terms will help to clarify why some work efforts are handled in one group or two.

• Application-related Standards, as they focus on development of business content utilizing existing technologies, are generally developed in a single group which creates the requirements AND approves the subsequent standards, or combined with other standards groups working on similar requirements

• Technology-related Standards, as they focus on business context neutral technologies, are developed in two groups, the first made up of business users who create the business requirements, and technical groups who develop a technical standard


Clarification of Application-related vs. Technology-related Standards

• As earlier stated, these terms are intended to give broad awareness of the nature of work in a given group. They do not represent explicit categorizations and it is foreseen that many work efforts may not readily fall into one category or another.

• Work efforts obviously at one extreme or the other will be dealt with through “preset” GSMP process settings

• Work efforts that are not obviously one or the other will be dealt with procedurally in the GSMP by an analysis to find the optimal way to address the specific work effort which will be captured in the group Charter and approved by the POC


GSMP Process Settings Decision Tool

Maintenance-related

Development-related

Technology-related

Application-related

Typically addressed by a new group that both analyzes requirements and develops the standard/guideline

(“narrow path” + “mission-specific group”)

Typically addressed by a new group that analyzes requirements, followed by a second new group that develops the

standard/guideline (possibly in response to several related requirements streams)

(“normal path” + “mission-specific group”)

Typically ad-

dressed by a

standing group

(“narrow path” + SMG)


Group Naming Based on Process Settings

Change Type

Group Group Lifetime

Process Flow Steps

Output

Maintenance Related(yellow box)

Standards Maintenance Group (SMG)

Standing 2+3+4 Approved Standards or Guidelines Change

Application Related(pink box)

Combined Development Group (CDG)

Mission Specific

2+3+4 Approved Business Requirements and Standard/ Guideline

Technology Related(blue box)

Requirements Development Group (RDG)

Mission Specific

2 Approved Business Requirements

Standards or Guideline Development Group (SDG or GDG)

Mission Specific

3+4 Approved Standard or Guideline (new or change to existing)

These names are more specific ways of describing a mission-specific WG, based on the process steps it is responsible for


Step 1: 25,000 Feet

Work request

with SBN Charter

Work request, no SBN

PCD

DraftCharter

Draft and issue call-to-action

ISDP 1b: process initiation [Dev]

Form WG

Review of SBN by WG to ensure it’s understood (consult with

IE as needed)

Vote to advance to next step

Call to Action

New C-Room

Omitted if standing SMG to be used

POCIE

SBN

SBN

IE

IE

Industry Roadmap

Ongoing Engagement with a given

Industry Work Request

Form SBN Team

Draft SBN

SBN Finalize SBN

PCD

PendingSBN

Work request originating from other

than IE

If a WR was submitted without a SBN, and it is substantial enough to warrant one, it is sent back to IE to review and create the SBN

ISDP 1a: stmt of need [IE]

Revise SBN if needed

71


Step 2: 25,000 Feet

BRADCharter,

SBNWork on BRAD

ISDP 2: requirements

Finalize(*) BRAD

Community review (*) of BRAD

Community

GAG

(*) “Finalize” implies a certain sequence of review and voting steps detailed on slide 14

SMGIf WG is mission-

specific reporting to an SMG

(*) “Community review” implies a certain sequence of review and voting steps detailed slide 15


Step 3: 25,000 Feet

BRAD

Work on Standard

ISDP 3: system development

Finalize(*) Standard

Community review(*)

Community

Optional

GAG

PCD

Prototype testing


UnratifiedStandard

Finalize(*) changes

POC

DevCharter

BRAD “Narrow” path

(*) “Community review” implies a certain sequence of review and voting steps detailed on slide 15

SMG

1st IP Review


Step 4: 25,000 Feet

ISDP 4: system development

Finalize(*) all

collateral

Community review(*)

Community

GAG

POC Ratification


POC BCS

RatifiedStandard

(*) “Community review” implies a certain sequence of review and voting steps detailed on slide 15

SMG

2nd IP Review

Board Ratification

Other Step 4

collateral

Work on collateral

Confirm collateral

list

UnratifiedStandard

Marketing, IE

Ongoing revisions

to collateral

POC


Step 4 open issues• Should impact assessment wait until Step 4, or be done in Step 3 prior to the first community review of draft standard?

• Rationale: we really ought to have thought through issues of compatibility and transition before the technical details have been finalized

• What is the complete list of collateral materials that might be created in Step 4? (see also next slide)• Impact assessment (but see above)

• Value proposition – based on SBN

• Scenarios / use cases

• Migration Plan

• Implementation plan

• Implementation guide – based on BRAD together with standard

• Marketing collateral

• Outreach

• How does WG engage non-WG resources in Step 4 (e.g., other SPs, IE, Marketing, other end users, MOs)? What if any IP policy issues arise from this?

• In most cases, this does not need to be formalized. WG can solicit help from outside if needed.

• If WG needs help from others, those others must either (a) opt in to WG; or (b) only be presented with work artifacts that have received prior community review

• Scope of community review in Step 4 – what is reviewed?• Andrew: I would allow everything to be reviewed. This is in line with our principles

• While the standard or guideline (previously reviewed in Step 3) is made available at this stage for reference, comments are not solicited on that and changes will not be made in Step 4.

• Scope of ratifications in Step 4 – standard only or also the collateral materials?• Andrew: implementation guidance, value proposition, migration plans and scenarios are ratified. I think marketing materials should be

excluded because opinions will be so subjective that consensus will be hard to achieve

• Michele: but what does “ratification” mean for other deliverables? For a standard, it means the standard cannot be changed without due process, but this may not be appropriate for guidance, migration plans, etc, which may evolve as they are used

• Conclusion: board does not “ratify” collateral. POC approves, and collateral may change post-ratification if needed

• Criteria for omitting some or all Step 4 deliverables• Andrew: Obviously errata and new codes don't need much if anything. Items coming out of CDGs or SDGs should have at least a value

proposition, operational guidance and scenarios

• Should Step 4 begin with an assessment of interest – do we want to continue with collateral development and ratification or have the needs of end users shifted since the work was initiated?


Step 4 deliverables

• Impact statement (move this to Step 3?)• Back compatibility, migration issues, etc

• Qualitative assessment of the size of the impact – difficulty, number of hours, etc.

• Value Proposition – based on SBN• tells members why they should bother to implement the standard in terms they can take to their budget holders for approval.

• is also the item that product marketing and business development functions in larger MOs will find useful in their communications

• Scenarios / use cases• To communicate the way that the standard is intended to be used (not in a restrictive way), helping to avoid divergent interpretations of

what the standard is

• Implementation / Migration plans. • If the output is a development of an existing standard (an update or a new version) 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 concerted community action? Do two (or more versions) co-exist and what are the sunrise and sunset dates?

• If the output is a new standard, 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 concerted 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?

• Including revisions to GS1 Services, if applicable; i.e. coordinating end user activity with activity of GS1 in deploying/upgrading GS1 Services

• Implementation guide – based on BRAD and the standard• For each business requirement, show how the relevant part of the standard can be used in an implementation to meet the requirement

• FAQs• Marketing collateral

• “Sales pitch”

• Analysis of other business needs for which the new standards or guidelines may play a role

• Materials related to overall GS1 strategy

• Outreach plan• Webinars

• Press releases

• Newsletters

• Bulletins

• E-mail distribution lists


Document Maturity Levels

• A document under development (BRAD in Step 2, Standard in Step 3, Collateral in Step 4) has a maturity level that indicates how far along the process it is

• Maturity levels are “ratchets” that ensure a one-pass flow:• At a given maturity level, a document may undergo revision

as development is performed or comments are processed

• A document’s maturity level advances at the completion of a process milestone marked by a vote, approval, or ratification

• A document never moves to an earlier maturity level Rare exception: POC may force rework due to IP claim or other

dire circumstance


Document Maturity Levels

WG development

WG review (+ GAG if no community review)

Community, GAG review

Prototyping

POC ratification

BCS ratification

Publication

Draft

Draft(penultimate)

Community ReviewDraft

Prototype Standard

Unratified Standard

Unratified Standard

Ratified Standard

Standard,prototyped

Draft

Draft(penultimate)

Community Review Draft

Unratified Standard

Unratified Standard

Ratified Standard

Standard,not prototyped

Final Document

Draft

Draft(penultimate)

Community Review Draft

BRAD, guideline, etc, with

community review

Final Document

Draft

Draft(penultimate)

BRAD, guideline, etc, without

community review What takes place while at that maturity level

Document Type


“Finalize” process

• Used to progress a document through a significant process gate (completion of development/test work)

Work on Document

Draft

Group Motion to Begin WG

Review

Draft (penultimate)

WG collects comments

using comment

form

WG resolves

comments

RevisedPenultimate

Draft

Group Vote to

Progress

CRD or FinalWorking

Draft

“Finalize” steps

“Motion” = takes place on concall or meeting; 2/3 of attendees “aye” + established minimums required to move forward. WG may decide to do this via Kavi ballot instead (and must do so if

minimums not met during a voice vote)

“Vote” = via Kavi; 2/3 “yes” votes + established minimums required to move forward. Exception: for finalization of requirements on “accumulated” path, this may be done via

concall motion instead


“Community Review” process

• Used to solicit and respond to community input

Community Review

Draft

Announce and

distribute to community

WG resolves

comments

RevisedComm. Review

Draft

Commu-nity Vote

to Progress

Prototype Standard

“Community Review” steps

“Vote” = via Kavi; 2/3 “yes” votes + established minimums required to move forwardParticipants in this vote include WG plus all community members who have signed IP policy

Community provides

comments via

comment form

Unratified Standard

Final Document

For a standard subject to prototype/pilot

For a standard not subject to prototype/pilot

For a BRAD, guideline, or other deliverable

Community

GAG

SMGIf WG is mission-

specific reporting to an SMG

Community


Putting it Together – 10,000 feet

WR

WR

PCD

Charter WD


Form WG

Final Charter

Final Charter,

SBN

Work on BRAD

BRAD CRD

Final BRAD

BRADPCD

BRAD

Work on Standard

Std CRD

BRAD Draft

Std D

Prototype Standard


SBN Finalize SBN

Finalize Standard

Prototype / pilot

Finalize Changes

Unratified Standard

Unratified Standard

Ratified Standard

Optional

ISDP 1: Statement of

Need

ISDP 2: Requirements

ISDP 3: Standards

“Narrow” path

“Aggregated” path

POC BCS

GAGCommunity

GAGCommunity

POC

POC

Finalize BRAD

Community Review BRAD

Community Review

Standard

POC Ratification

BCS Ratification

Dev Charter

Final SBN

Omitted if “fast” path used

IE

Review SBN

IE

IE


Putting it together – 5,000 feet

WR

WR

PCD

Charter WD


Form WG

Review SBN


Group Motion

SBNCollect, resolve

comments

SBNGroup Vote

Final Charter

Final Charter,

SBNWork on BRAD

Group Motion

BRAD PD

Collect, resolve

comments

BRAD PD

Group Vote

BRAD CRD

Ann’ce, Collect, resolve comm’ty

comments

BRAD CRD

Community Vote

Final BRAD

Finalize charter

Finalize BRADCommunity review BRAD

BRADPCD

BRAD

Work on Standard

Group Motion

Std PD

Collect, resolve

comments

Std PD

Group Vote

Std CRD

Ann’ce, Collect, resolve comm’ty

comments

Std CRD

Community Vote

P

Finalize StandardCommunity review

BRAD Draft

Std D

P Prototype/ pilot

Collect, resolve

comments

P Group Vote

Finalize Changes

U POC Ratification

U BCS Ratification

Ratified Standard

Optional

ISDP 1

ISDP 3

ISDP 2

POC BCS

GAGCommunity

GAG

Community

POC

POC

“Narrow” path

“Aggregated” path

Dev Charter

IE

Final SBN

IE

IE


IP Review

• 1st 30-day IP review begins when we reach Prototype Standard, and runs concurrently with prototype/test.

• 2nd 30-day IP review begins when we reach Unratified Standard, and runs concurrently with POC review

• POC review may complete with a “conditional approval,” after which:• If no IP claims are made, std progresses directly to board ratification

• If IP claims are made, POC reviews again, and decides either Send std back for rework in light of IP claims; or Progress to board ratification with IP issues noted

• If no prototype/test phase, then 1st IP review is omitted• Release of std to ISO or other SDO takes place after 2nd IP

review completes


Deliverables: 1,000 foot view

• ISDP 1: statement of need• Charter + SBN

• Original Work Requests referenced by charter

• Call to Action (if applicable, for archival purposes)

• Record of group vote to advance

• Minutes of all meetings

• ISDP 2: requirements• Final BRAD

• Record of group vote and (if applicable) community vote

• Completed comment resolution form(s)


• ISDP 3: standards• Final standard

• Record of all group and community votes

• Completed comment resolution forms from WG review, community review, post-pilot/prototype review

• Mapping of requirements to final standard

• Conformance requirements (if applicable)



Mapping to OE 3a process flow

Industry EngagementStatement of Business Need

Ad HocGroup

Prioritization & Feasibility

Step

2- Req

Step

3 - Dev

Step 1

Step 4Deployment

Ad Hoc Group

Ad HocGroup

StandingGroup

Simple ChangeRequests

Complex Application Stds

Complex Tech Standards

Solutions and Services

Ste

p 2

an

d 3

– R

eq

an

d D

ev

Ste

p 2

an

d 3

– R

eq

an

d D

ev

WorkIn

Progress

Sys

tem

s D

evel

op

men

t

ISDP 1 (PDC step)

ISDP 2 + 3, SMG & “Narrow path” selected

ISDP 2 + 3, “Narrow path”

selected

ISDP 2 + 3, PDC step between


Other Process Variations

• GSMP “project”• Same ISDP process used• Timelines and resources may be different

• Sector project• Same ISDP process used

• Guideline• Same ISDP steps are used, except:

Deliverable in Step 2 is an outline for what use cases will be addressed by guideline, not “requirements” in the same sense as the word is used in standards development

Deliverable in Step 3 is the guideline Prototyping in Step 3 is almost certainly omitted

• GAG review in Step 3 is essential to confirm that the output is truly a guideline, not a standard, according to the GAG’s established definition


Unresolved Process Issues

• TBD: Criteria for when it is acceptable to specify the “narrow” and “accumulated” paths.• Partly addressed on Slide 39

• TBD: Criteria for when it is acceptable to route work to an SMG rather than an mission-specific working group• Partly addressed on Slide 39

• TBD: Under what circumstances can Step 2 be omitted or have a lighter weight output than a full BRAD (or outline, in the case of a guideline)?

• TBD: Policy for acknowledging contributors on finished standards

• TBD: Identify exception conditions in process flow (e.g., if call to action fails to gather sufficient interest)


Old GSMP (Complex), EPC SDP, New GSMP Compared

Receive, process and monitor change

request

GSMP C1.1

Create & announce a call to action

GSMP C1.2

Form volunteer user group (e.g.,

requirements group, work group)

GSMP C1.3

Review & agree with the stated business need

GSMP C1.4Gate 1

Motion to Progress Opens

work order & progresses to

step 2

Collect Business and Technical Requirements

EPC 1

Form JRG

EPC 2

Technical Definition with End Users

(JRG)

EPC 3

Sources:BusinessTechnicalPrivacy

Note: not explicit in EPC SDP, but likely done as part of EPC Step 3

Architecture Review

WR

WR

PCD

Charter WD

Draft and issue call-to-

actionForm WG

Review SBN

Final Charter,

SBN


SBN WD

POCISDP 1

Finalize SBN

IE?

IE? IE?

Omitted on “narrow” path



Gather and analyze requirements

GSMP C2.1

Assign context, modeling

components & standard definitions

from GDD

GSMP C2.2

Complete review of Requirements

Documents

GSMP C2.3

Gate 2Motion to Progress

Progresses work to step 3

Technical Definition with End Users

(JRG)

EPC 3

End User Requirements

Development (JRG)

EPC 4

End User Requirements

Development (JRG)

EPC 4 (cont’d)

BSC & TSC Approval of JRG

Requirements

EPC 5

Architecture Review

Note: no EPC equivalent

Architecture Review

Final Charter Work on BRAD

BRAD LCWD

Final BRADBRAD

WD

GAGCommunityGAG if not later

Finalize BRAD

Community Review BRAD

Optional

ISDP 2



Prepare appropriate GS1 documents

GSMP C3.1

Facilitate WG Review

GSMP 3.2

Resolve WG review comments

GSMP C3.3

Gate 3Motion To Progress

Progresses work to Step 4

Working Group Formation

EPC 6

Standards Development

EPC 7

Note: in EPC SDP, comparable steps are identified as sub-steps within EPC step 7

Note: in GSMP, same WG does requirements and technical development. In EPC SDP, JRG does requirements, then technical WGs are formed as needed – latter not necessarily 1:1 with JRG

BRADPCD

BRAD

Work on Standard

Std LCWD

Std WD

Finalize Standard

“Narrow” path

POC

Dev Charter

ISDP 3 (part)



Facilitate public review with BRG

comments

GSMP C4.1

Resolve public review and BRG

comments

GSMP 4.2

Facilitate eBallot

GSMP C4.3

Gate 4Ratification

Recommendation by Process

Group

Action Group Review and

Approval

EPC 8

Motion To Progress to

eBallot

Architecture Review Initiate 1st 30-day IP review

Note: no GSMP equivalent

Note: in EPC SDP, comparable steps are identified as sub-steps within EPC step 8 Note: corresponds to EPC Steps 10 & 11, next slide

Architecture Review

GAGCommunity

Community Review Standard

Std LCWD

ISDP 3 (part)



Process call to action for pilot

test team

GSMP C5.1

Develop pilot test

plan

GSMP 5.2Gate 4

Ratification Recommendatio

n by Process Group

Prototype Test of Specification

EPC 9

Imple-ment

pilot test plan

GSMP 5.3

Report pilot test results

GSMP 5.4

Develop & present

recommen-dations

GSMP 5.5Gate 5

Motion to Progress Final pilot test report

Committee Review (BSC &

TSC)

EPC 10

Board Ratification

EPC 11

Note: in EPC SDP, ratification recommended only after prototype

phase completes

Note: in EPC SDP, prototyping usually leads to a revised draft

Initiate final 30-day IP review

Note: no GSMP equivalentPossible submission to other

standards body

Note: no GSMP equivalent

Candidate Standard Prototype / pilot Finalize

Changes

Proposed Standard

Recom- mended Standard

Ratified Standard

Optional

POC BCS

POC Ratificati

on

BCS Ratification

ISDP 3 (part) 1st IP Review 2nd IP Review



Close work order

GSMP 6.1

Post approved standard or solution

to website

GSMP 6.2

Announce posting of the standard or

solution

GSMP 6.3

Prepare board ratification notice

GSMP 6.4

Note: Similar things happen for EPCglobal standards, but they are not formal steps in the EPC SDP

ISDP 4 (TBD)


Step 4

• Criteria for including collateral work in the ISDP process manual:• Interaction with the WG

Pre-ratification (Steps 1, 2, 3) Post-ratification (Step 4)

• Steps that need to be executed consistently, and with visibility as to what steps have been completed

• Interdependences – e.g., ratification of Standard A requires changes to Guideline B, Training Program C, etc

• Things that are mission critical to deployment of standard; e.g.: Solution provider program Training material Policy maker outreach Certification/test services Marketing comm collateral Migration plans (e.g., version handing, sunset dates, etc)


Outline

• GSMP Principles [Team 1]

• Participation

• General Policies• Group Leadership

• Anti-trust Caution, Code of Conduct

• IP Policy

• Teleconferences and Physical Meetings

• Consensus / Decision Making

• Voting Procedures

• Appeals

• Loss of Participation Rights and Reinstatement

• Access to Work in Progress and Confidentiality



• Governance Groups POC GAG BCS

• Process Flow

• Community Interaction

• Infrastructure


ISDP Process Team 2 – Community Sub-Team Status

Templates Proposed to be state Next Steps

Call to Action Template

Define and Create a new CTA Template

Post new model development

Process Change Notification

New Template Post new model development

Press Releases Proposal submitted Post new model – resolve comments and incorporate new model into proposal

Newsletters Create New Template Post new model

Member on/off boarding

Proposal submitted Post new model – resolve comments and incorporate new model into proposal

Charter Template Define and create a new GSMP process Charter Template based on the existing EPCglobal charter, GS1 PDD, GDSN BCD

Post new model development


ISDP Process Community – Internal Processes To-Be-Defined Post New Model

Process To be Defined Next Steps

Public Review

Arch Review

Community Room Best Practices for Users and Facilitators


Outline

• GSMP Principles [Team 1]

• Participation

• General Policies• Group Leadership

• Anti-trust Caution, Code of Conduct

• IP Policy

• Teleconferences and Physical Meetings

• Consensus / Decision Making

• Voting Procedures

• Appeals

• Loss of Participation Rights and Reinstatement

• Access to Work in Progress and Confidentiality



• Governance Groups POC GAG BCS

• Process Flow

• Community Interaction

• Infrastructure


ISDP Process Team 2 - Infrastructure Sub-Team Status

Infrastructure Proposed to be state Next Steps

GS1 Community Room and EPCglobal Subscriber site

Proposal submitted – Integrate EPCglobal Subscriber site and the GS1 Community Room

Post new model platform integration

GSMP CR System and EPC ER System

Proposal submitted - Integrate new process and EPCglobal requirements into the exiting GSMP Change Request System

Post new model platform integration

Audio Visual tools (Live meeting and Premier Global) will remain the same

Use Live Meeting and Premier Global for AV meeting tools

Use Zoomerang as the survey tool

Complete – no change

Internal development tools : GSMP - Visio, Perforce, Rational Rose

GSMP – no change. EPCglobal to use Perforce for standard development repository.

Team 6 Publications is defining the standard document process. Re-revisit with development team post integration for review