Purchasing Reliability Working Group

Attributes

Business Goals

A purchase and ordering system that is well-documented and easily understood by all stakeholders. The system will be resilient, reliable, and observable from the ground up. In addition to addressing our current use-cases, the system will easily accommodate the addition of new purchasing workflows (like channel partners), metered billing, and project Horse. Finally, this should all be achieved without sacrifices to the buyer experience. Touchpoints with the product(s) should be even more seamless than they are today, especially if/as we begin surfacing up-sell opportunities directly in the product.

Definitions

What is Purchasing?

At GitLab, “fulfillment” generally refers to the Fulfillment Sub-department of Engineering.

To avoid confusion, this Working Group uses “purchasing” as an all-encompassing term to describe the end-to-end purchasing experience including (but not necessarily limited to) ordering, billing, licensing, fulfillment, and all of our internal workflows (like lead generation for Sales, and reporting for Finance).

Be aware if you see the term “fulfillment” used casually in the context of this Working Group, it is likely referring to the entire “purchasing system”, not the Fulfillment Sub-department specifically.

Related Projects & Documentation

Slack channels

• #s_fulfillment
• #s_fulfillment_engineering
• #enterprise-apps
• #bt-integrations

Prior Art

• Commercial & Licensing Working Group
  • Handbook Page
  • Agenda Doc
  • Purpose: Define business & customer experience requirements for a system to handle commercial and licensing transactions into the future.
  • Outcomes:
    • Zuora Single Source of Truth Discusssion Paper
    • ???

Infrastructure

Infrastructure team is committed to supporting Fulfillment in the migration of CustomersDot from the legacy Azure VM to GCP by the end of 2022-01. See the discussion in 2021-11-30 Engineering Allocation Review) for details.

This will help bring CustomersDot in line with the rest of our application stack in terms of how it is operated, but the application will still need to be instrumented and alerting configured to address our current lack of observability and insight into this app.

Engineering (Fulfillment)

• CustomersDot
• gitlab-org&3602: GitLab <> Customers, License, Zuora Integration

Enterprise Apps

• Quote to Cash
• Platypus
• gitlab-com/business-technology/enterprise-apps&293: Distributor e-Marketplace

Sales

• Sales Systems (i.e. Salesforce)
• Internal Sales Handbook Definitions
• Booking Metric Technical Docs

Exit Criteria

The charter of this working group is to obtain alignment between stakeholders (i.e. Engineering (Development), Enterprise Apps, Sales, and Finance). This includes addressing some immediate-term technical debt as well as defining a clear vision and team/service boundaries going forward.

1. Infrastructure roadmap for each system defined
2. Data models for each system including sources of truth defined
3. System integrations of Order to Cash systems defined
4. Change management mechanisms across teams defined
5. FY23 team structure and staffing plans for each team defined, with a view into committed roadmap items ~2 quarters out for cross-team coordination.

Roles and Responsibilities

View page source - Edit this page - please contribute.