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

From ZUGSEIL Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by the same user not shown)
Line 13: Line 13:
* '''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
* '''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


=== Roles in the context based ordering process ===
== Examples ==
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:
These two examples explain the value for context-based ordering


====== General management ======
====== Transportation industry & Personal Protective Equipment ======
The general management creates the context based shopping purpose once. After this is done, the [[Dev:Context definition process|context definition process]] allows the creation of contexts, in which the mandatory informaiton is set:
<u>Usecase</u>: 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


* generally available product groups for this product
<u>Solution</u>: 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:
* generally usable category structure with attached search attributes
*The <u>strategic buyer</u> 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.
* assigns team members and team roles
*The <u>PPE demand leads ("Teamleiter")</u> define '''team type/job profile specific products''' by throwing out undesired or not required products or full product categories for the team.
{{Note|Typically this step is '''not''' done manually, but is rather done by interfaces, which tap into the ERP system and create contexts automatically.}}
*The <u>demand side ("Mitarbeiter")</u> will only see the products made available from its team leads.
The [[Dev:Context definition process|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 ======
====== Construction industry ======
After the opening of the context these data need to be defined:
<u>Usecase</u>: 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.


* suppliers available for online ordering
Solution: Each of the projects receives its own context. Generally this flow is adhered:
* 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 pickup-sites)


'''Context operative manager role'''
* 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 <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads


After the context is opened the operative manager:
== See also ==


* 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.
* [[App:Contextbased Ordering Manager]]
* manages team members
* [[App:Team manager]] - To manage CBO properties on team level (upgraded to
* manages approval strategies inside the contexts teams
* [[App:Project Administration]] - For managing projects and CBO properties on projects
* [[App:Facilities Administration]] - For workplace administration
* [[App:Organization units administration]] - For managing CBO properties on organization units
* [[App:Business participant groups administration]] - To manage CBO properties on BP group level


====== Demand side role ======
<u>For Developers</u>
This role is creating demand by using the shop
*[[Dev:Context definition process]]
 
====== Demand leader role ======
This role has the same functionality as the demand side role, extended by approval functionality for demand before the purchasing process is triggered.
 
 
 
 
 
 
=== 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.
====Example for team ordering in the domain of Personal Protective Equipment====
This example is typical for personal protective equipment, which is highly regulated as it ensures the protection of staff.
*The <u>strategic buyer</u> for personal protective equipment (PPE) defines '''suppliers''' and accepts their catalogs. These catalogs are the foundation for PPE procurement.
*The organization's <u>PPE lead</u> for personal protective equipment defines '''team type/job profile specific catalogs''', predefining from which products the team managers can decide for their staff members
*Depending on the team type / job profile the <u>team managers</u> can adopt the entire catalogs from the PPE lead and eventually add or remove individual articles from PPE lead catalogs.
*The <u>team member</u> will only see the products made available from its team leads.
 
== 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]]

Latest revision as of 17:28, 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

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

See also

For Developers