isdp process integration subgroup team 2 draft consolidated to be state n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State PowerPoint Presentation
Download Presentation
ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State

Loading in 2 Seconds...

play fullscreen
1 / 69

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


  • 104 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ISDP Process Integration Subgroup (Team 2): DRAFT Consolidated “To Be” State' - alphonse-meller


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
isdp process integration subgroup team 2 draft consolidated to be state

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

2 September 2009

outline
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
outline1
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 (POC)
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure
participation
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
participation1
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)
categorization of participating organizations
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
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)
outline2
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)
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure
group leadership
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
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

Subject to Team 4 Review

  • 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
ip policy opt in and opt out
IP Policy: Opt in and opt out

Subject to Team 4 Review

  • 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
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
Decision Methods
  • Group consensus is overriding principle.
  • Four methods used:
voting details
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
  • 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
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
Loss of Participation Rights and Reinstatement

Subject to Team 4 Review

  • 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
Access to Work in Progress and Confidentiality

Subject to Team 4 Review

  • 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.
outline3
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)
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure
organization
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
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
outline4
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)
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure
system development process per oe 3a
System Development Process per OE 3a

1 Statement of Business Need

Clear Definition Of Need

2 Requirements Development

Requirements

Document

3 GS1 System Development

Ratified Standards, Guideline, Approved Solutions, Services

Publications, Marketing, Support Tools and Training

4 Deployment

graphics
Graphics

Do Something

= An activity performed by a group

Doc

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

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

5

isdp to be 50 000 foot view
ISDP “To Be” – 50,000 foot view

Primarily SD

Primarily IE

SBN

ISDP 1a: stmt of need

ISDP 1b: process initiation

ISDP 2: require-ments

ISDP 3: stan-dards

ISDP 4: deploy-ment

WorkRequest

SBN

BRAD

UnratifiedStandard

Standard

Charter

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

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

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

handling of parallel work streams
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

PCD

ISDP “To Be” – 40,000 foot view

“Accumulated” BRAD path

ISDP 1: stmt of need

ISDP 3: stds

ISDP 2: require-ments

5

If SBN needed

PCD

34

DevCharter

Std

Work

PCD

PCD

WR

DraftCharter

Charter, SBN

BRAD

Work

Work

DevCharter

Std

WR

Work

WR

SBN

DraftCharter

Charter, SBN

BRAD

Work

Work

Work

DevCharter

Std

Work

WR

SBN

DraftCharter

Charter, SBN

BRAD

Work

Work

Work

Std

Work

WR

“Narrow” BRAD path

Primarily IE

Primarily SD

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

= Prioritize, Consolidate, Distribute

Work

charter ingredients
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
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
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
GSMP Work Order Spectrum

Maintenance-related

Development-related

  • 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 versus development related orders
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
Spectrum for Standards & Guidelines Content

Application-Related

Technology-Related

  • 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 vs technology related standards guidelines
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
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
GSMP Process Settings Decision Tool

Technology-related

Typically ad-dressed by a standing group

(“narrow path” + SMG)

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”)

Maintenance-related

Development-related

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

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

Application-related

group naming based on process settings
Group Naming Based on Process Settings

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
Step 1: 25,000 Feet

ISDP 1a: stmt of need [IE]

Industry Roadmap

PCD

Ongoing Engagement with a given Industry

Work Request

Form SBN Team

Draft SBN

SBN

Finalize SBN

PendingSBN

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

Revise SBN if needed

ISDP 1b: process initiation [Dev]

Vote to advance to next step

Omitted if standing SMG to be used

Review of SBN by WG to ensure it’s understood (consult with IE as needed)

PCD

Work request with SBN

Charter

SBN

DraftCharter

Draft and issue call-to-action

Form WG

Work request, no SBN

SBN

Work request originating from other than IE

Call to Action

New C-Room

IE

IE

POC

71

IE

step 2 25 000 feet
Step 2: 25,000 Feet

ISDP 2: requirements

Community review (*) of BRAD

Work on BRAD

Finalize(*) BRAD

Charter, SBN

BRAD

Community

GAG

If WG is mission-specific reporting to an SMG

SMG

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

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

step 3 25 000 feet
Step 3: 25,000 Feet

ISDP 3: system development

POC

Optional

PCD

1st IP Review

BRAD

DevCharter

Community review(*)

Prototype testing

Finalize(*) changes

UnratifiedStandard

Work on Standard

Finalize(*) Standard

BRAD

“Narrow” path

Community

GAG

SMG

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

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

step 4 25 000 feet
Step 4: 25,000 Feet

ISDP 4: system development

2nd IP Review

Community review(*)

POC Ratification

Board Ratification

Ongoing revisions to collateral

RatifiedStandard

UnratifiedStandard

Confirm collateral list

Work on collateral

Finalize(*) all collateral

Other Step 4 collateral

Marketing, IE

Community

POC

BCS

POC

GAG

SMG

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

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

step 4 open issues
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
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
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 levels1

WG development

WG review (+ GAG if no community review)

Community, GAG review

Prototyping

POC ratification

BCS ratification

Publication

Document Maturity Levels

Document Type

BRAD, guideline, etc, without community review

BRAD, guideline, etc, with community review

Standard,not prototyped

Standard,prototyped

What takes place while at that maturity level

Draft

Draft

Draft

Draft

Draft(penultimate)

Draft(penultimate)

Draft(penultimate)

Draft(penultimate)

Community Review Draft

Community Review Draft

Community ReviewDraft

Prototype Standard

Unratified Standard

Unratified Standard

Unratified Standard

Unratified Standard

Final Document

Final Document

Ratified Standard

Ratified Standard

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

WG collects comments using comment form

WG resolves comments

RevisedPenultimateDraft

CRD or FinalWorkingDraft

Group Motion to Begin WG Review

Group Vote to Progress

Draft (penultimate)

Work on Document

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
“Community Review” process
  • Used to solicit and respond to community input

Prototype Standard

For a standard subject to prototype/pilot

Announce and distribute to community

Community provides comments via comment form

WG resolves comments

RevisedComm. Review Draft

Commu-nity Vote to Progress

Community ReviewDraft

Unratified Standard

For a standard not subject to prototype/pilot

Final Document

For a BRAD, guideline, or other deliverable

“Community Review” steps

Community

Community

GAG

If WG is mission-specific reporting to an SMG

SMG

“Vote” = via Kavi; 2/3 “yes” votes + established minimums required to move forward

Participants in this vote include WG plus all community members who have signed IP policy

putting it together 10 000 feet
Putting it Together – 10,000 feet

ISDP 1: Statement of Need

Omitted if standing SMG to be used

Omitted if “fast” path used

IE

Final SBN

POC

PCD

WR

Draft and issue call-to-action

Form WG

Finalize SBN

Charter WD

Review SBN

SBN

Final Charter

WR

IE

IE

ISDP 2: Requirements

“Aggregated” path

Work on BRAD

Finalize BRAD

BRAD CRD

Community Review BRAD

Final BRAD

Final Charter, SBN

BRAD Draft

Community

GAG

ISDP 3: Standards

POC

Community

PCD

GAG

BRAD

Dev Charter

Work on Standard

Std D

Finalize Standard

Std CRD

Community Review Standard

BRAD

“Narrow” path

Prototype / pilot

Finalize Changes

POC Ratification

BCS Ratification

Prototype Standard

Unratified Standard

Unratified Standard

Ratified Standard

POC

BCS

Optional

putting it together 5 000 feet
Putting it together – 5,000 feet

Omitted if standing SMG to be used

IE

ISDP 1

Finalize charter

POC

Final Charter

PCD

IE

Draft and issue call-to-action

Form WG

Group Vote

WR

Review SBN

Group Motion

SBN

Collect, resolve comments

SBN

Charter WD

Final SBN

WR

IE

ISDP 2

Community review BRAD

Finalize BRAD

Ann’ce, Collect, resolve comm’ty comments

Community

Final Charter, SBN

Work on BRAD

Group Motion

BRAD PD

Collect, resolve comments

BRAD PD

Group Vote

BRAD CRD

BRAD CRD

Community Vote

Final BRAD

BRAD Draft

GAG

“Aggregated” path

Community review

POC

Finalize Standard

Community

GAG

PCD

Ann’ce, Collect, resolve comm’ty comments

BRAD

Dev Charter

Work on Standard

Std D

Group Motion

Std PD

Collect, resolve comments

Std PD

Group Vote

Std CRD

Std CRD

Community Vote

P

BRAD

“Narrow” path

Finalize Changes

Prototype/ pilot

Collect, resolve comments

P

Group Vote

U

POC Ratification

U

BCS Ratification

Ratified Standard

P

POC

BCS

ISDP 3

Optional

ip review
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
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)
    • Minutes of all meetings
  • 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)
    • Minutes of all meetings
mapping to oe 3a process flow

Industry Engagement

Statement of Business Need

Step 1

Prioritization & Feasibility

Complex

Application Stds

Simple Change

Requests

Solutions and

Services

Complex

Tech Standards

Ad Hoc

Group

Ad Hoc

Group

Standing

Group

Step 2- Req

Work

In

Progress

Systems Development

Step 2 and 3 – Req and Dev

Step 2 and 3 – Req and Dev

Ad Hoc

Group

Step 3 - Dev

Step 4Deployment

Mapping to OE 3a process flow

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
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
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
Old GSMP (Complex), EPC SDP, New GSMP Compared

GSMP C1.1

GSMP C1.2

GSMP C1.3

GSMP C1.4

Gate 1Motion to Progress Opens work order & progresses to step 2

Receive, process and monitor change request

Create & announce a call to action

Form volunteer user group (e.g., requirements group, work group)

Review & agree with the stated business need

EPC 1

EPC 2

EPC 3

Collect Business and Technical Requirements

Form JRG

Technical Definition with End Users (JRG)

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

Sources:BusinessTechnicalPrivacy

Architecture Review

ISDP 1

Omitted if standing SMG to be used

Omitted on “narrow” path

IE?

POC

PCD

Draft and issue call-to-action

Form WG

Review SBN

Finalize SBN

WR

Charter WD

SBN WD

Final Charter, SBN

WR

IE?

IE?

old gsmp complex epc sdp new gsmp compared1
Old GSMP (Complex), EPC SDP, New GSMP Compared

Architecture Review

GSMP C2.1

GSMP C2.2

GSMP C2.3

Gate 2Motion to Progress Progresses work to step 3

Gather and analyze requirements

Assign context, modeling components & standard definitions from GDD

Complete review of Requirements Documents

Note: no EPC equivalent

EPC 3

EPC 4

EPC 4 (cont’d)

EPC 5

Technical Definition with End Users (JRG)

End User Requirements Development (JRG)

End User Requirements Development (JRG)

BSC & TSC Approval of JRG Requirements

Architecture Review

Finalize BRAD

Community Review BRAD

Work on BRAD

Final BRAD

BRAD LCWD

Final Charter

BRAD WD

GAG if not later

Community

GAG

ISDP 2

Optional

old gsmp complex epc sdp new gsmp compared2
Old GSMP (Complex), EPC SDP, New GSMP Compared

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

GSMP C3.1

GSMP 3.2

GSMP C3.3

Gate 3Motion To Progress Progresses work to Step 4

Prepare appropriate GS1 documents

Facilitate WG Review

Resolve WG review comments

EPC 6

EPC 7

Working Group Formation

Standards Development

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

POC

PCD

Work on Standard

Finalize Standard

Std LCWD

BRAD

Dev Charter

Std WD

BRAD

“Narrow” path

ISDP 3 (part)

old gsmp complex epc sdp new gsmp compared3
Old GSMP (Complex), EPC SDP, New GSMP Compared

Note: corresponds to EPC Steps 10 & 11, next slide

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

Facilitate public review with BRG comments

GSMP C4.1

Resolve public review and BRG comments

GSMP 4.2

Motion To Progress to eBallot

GSMP C4.3

Facilitate eBallot

Gate 4Ratification Recommendation by Process Group

Architecture Review

EPC 8

Action Group Review and Approval

Initiate 1st 30-day IP review

Architecture Review

Note: no GSMP equivalent

Community Review Standard

Std LCWD

ISDP 3 (part)

Community

GAG

old gsmp complex epc sdp new gsmp compared4
Old GSMP (Complex), EPC SDP, New GSMP Compared

Note: in EPC SDP, ratification recommended only after prototype phase completes

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

GSMP C5.1

GSMP 5.2

GSMP 5.3

GSMP 5.4

GSMP 5.5

Gate 5Motion to Progress Final pilot test report

Gate 4Ratification Recommendation by Process Group

Process call to action for pilot test team

Develop pilot test plan

Imple-ment pilot test plan

Report pilot test results

Develop & present recommen-dations

EPC 10

EPC 11

EPC 9

Committee Review (BSC & TSC)

Board Ratification

Prototype Test of Specification

Initiate final 30-day IP review

Possible submission to other standards body

Note: no GSMP equivalent

Note: no GSMP equivalent

ISDP 3 (part)

1st IP Review

2nd IP Review

Prototype / pilot

POC Ratification

BCS Ratification

Candidate Standard

Finalize Changes

Recom- mended Standard

Ratified Standard

Proposed Standard

POC

BCS

Optional

old gsmp complex epc sdp new gsmp compared5
Old GSMP (Complex), EPC SDP, New GSMP Compared

GSMP 6.1

GSMP 6.2

GSMP 6.3

GSMP 6.4

Close work order

Post approved standard or solution to website

Announce posting of the standard or solution

Prepare board ratification notice

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

ISDP 4 (TBD)

step 4
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)
outline5
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
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure
outline6
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
      • POC
      • GAG
      • BCS
  • Process Flow
  • Community Interaction
  • Infrastructure