Difference between revisions of "Context based ordering assistant (CBO)"

From ZUGSEIL Wiki
Jump to navigation Jump to search
Line 70: Line 70:
* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads  
* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads  
 
=== Related articles ===
 
 
 
 
 
=== Context defining objects ===
Each of these objects allow the definition of a individual procurement contexts
 
* '''business participant groups'''
* '''teams'''
* '''[[Dev:CBO - Projektspecific Contexts|projects]]'''
*'''project phase'''
* '''workplace types'''
* '''organization units'''
{{Note|When a users enters the membership based ordering assistant mulitple context may display, if the user is member to multiple objects which permit context based ordering.}}
 
 
 
 
It allows predefined stakeholders of a context based ordering process to work together in a collaborative environment. Typical stakeholders are:
*Strategic buyer
*Organization's operative buyers / lead buyers
* Operative team managers
*Team members
Ultimately the ''context based ordering assistant'' allows team members to shop from a product sortiment, which is narrowed down to exactly the demand and organizational requirements.
*
 
== Development articles ==
 
* [[Dev:ZUGSEIL Shop - Translations|Translations]]
 
* [[Dev:Context based ordering - Versions|Versions]]
 
* [[QA:Context based ordering - Acceptance criteria|Acceptance criteria]]
 
* [[QA:Context based ordering - Acceptance tests|Acceptance tests]]
 
== Related articles ==
*[[Dev:Context based ordering assistant]]
*[[Dev:Context based ordering assistant]]


[[Category:Shopping assistants]]
[[Category:Shopping assistants]]

Revision as of 12:37, 7 December 2025

The context based ordering assistant allows a user to shop in one or more predefined procurement contexts. Contexts are made available to individual users in the context definition process

It is part of our advanced guided buying tools & ordering assistants extension of ZUGSEIL Shop.

Purpose

Each context bears individually optimizied catalog category hierarchy and a set of specific products which target explicitly this context. This speeds up the shopping process and provides a better shopping experience.

Benefits
  • Increased productivity - by reducing time for ordering products
  • Reduction of maverick buying - regular users may only order predefined products, and may not purchase "out-of-scope" products
  • Procurement governance - For each context specific approval processes may be defined, leading to faster and more controllable purchasing processes.
  • Multi-Tier Purchasing Knowledge-Management - Each of the purchasing participants can bring its knowledge to the table and through this reduce complexity and changes for wrong purchasing decisions

Context based definition and collaboration

Especially the knowledge management for the context is a central functionality for the context based ordering process to work. For optimal results, these roles work together in this way:

General management

The general management creates the context based shopping purpose once. After this is done, the context definition process allows the creation of contexts, in which the mandatory informaiton is set:

  • generally available product groups for this product
  • generally usable category structure with attached search attributes
  • assigns team members and team roles
Typically this step is not done manually, but is rather done by interfaces, which tap into the ERP system and create contexts automatically.

The context definition process also allows the definition of default values for a context, which can be used in the interface process or during manual definition of a context. Still, after the context is defined, the collaboration starts from these default values by these roles.

Strategic buyer role

After the opening of the context these data need to be defined:

  • suppliers available for online ordering
  • suppliers available for preordering at predefined pickup-sites
  • products available for internal ordering (and internal fulfillment)
  • internally available for internal ordering (and pickup at predefined internal pickup-sites)

Context operative manager role

After the context is opened the operative manager:

  • further manages available products to the context, reducing the products with the knowledge he has on work to delivery and goods required for this project.
  • manages team members
  • manages approval strategies inside the contexts teams
Demand side role

This role is creating demand by using the shop

Demand leader role

This role has the same functionality as the demand side role, extended by:

  • ability to leave the context and purchase from the base catalogs defined by the strategic buyers
  • approval functionality for demand before the purchasing process is triggered.

Examples

These two examples explain the value for context-based ordering

Transportation industry & Personal Protective Equipment

Usecase: The ordering of Personal Protective Equipment (PPE) in a large scaled public transportation company (SBB) is structured by teams, which are dedicated for specific jobs. Each of these jobs require specific equipment. Since some of these equipment are either expensive or need to be certified for the jobs, an approval process by the team managers is essential for specific processes

Solution: Each of these teams receive their own context. Cross-functional teams receive their own contexts. Staff members, which are in multiple teams are member of multiple teams, receiving their contexts. Generally this flow is adhered:

  • The strategic buyer for personal protective equipment (PPE) defines suppliers and manages their catalogs. Also a "internal ordering" PPE category structure with PPE specific search attributes is defined by the strategic buyers and is mapped to the relevant suppliers catalogs.
  • The PPE demand leads ("Teamleiter") define team type/job profile specific products by throwing out undesired or not required products or full product categories for the team.
  • The demand side ("Mitarbeiter") will only see the products made available from its team leads.
Construction industry

Usecase: Each construction site requires speicifc material depending on the project type. Project types are in a multi level hierachy, e.g. "Hochbau" -> "2-Familiehaus 7 Einheiten". This approach allows the definition of typical project phases and allows assignment of typically required products generally and per project phase. To avoid redundant spend and maverick buying, for specific or expensive equipment demand approval flows are required.

Solution: Each of the projects receives its own context. Generally this flow is adhered:

  • Automatic project generation - Projects are defined in the ERP and are transmitted via an interface and classified by a project type automatically. For each of these project types a default context is defined from which the basic settings are inherited.
  • The strategic buyer at the HQ manages suppliers, categories and products. This typically happends by removing settings not suitable or not desired for this project.
  • The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
  • The demand side role ("Polier") will by default only see the products made available from its team leads

Related articles