Success of an auction event depends upon completion of event with win-win situation for both (event owner and participants). To create winning combination event owners and participants to understand auction templates features and functionalities in totality and follow the best practices laid down by Ariba.
These templates are configured considering best practices of sourcing and to suites to most of the industry or business requirements, however, to make configuration tasks simpler, Ariba has identified few mandatory attributes in auction template. Event owner can configure only these and execute successful event. Apart from solution (template),event owner needs to understand significance of these mandatory attributes in connection with business processes.
In my earlier blogs, I have explained about how to create different type of auctions with the help of use cases, here,I am detailing out configuration of mandatory attributes for successful completion of auction event. User actions and system response/action in line with configured mandatory parameters are captured in table below.
Bid history (participants & system actions) of a completed forward auction event:
Let’s understand significance of above mandatory attributes (Event duration, bid increment, overtime, rank, front and reverse buffer) with the help of configuration of forward auction event in Ariba sourcing module.
After creating sourcing project, event owner to select first, event type under drop down menu(one of the prerequisite) to proceed further, for our use case we have selected “forward auction”.
Once event owner select applicable event, system automatically picks pre -configured templates & display appropriate templates.
Select a Template:
Surrogate bidding is enabled at template level by Ariba administrator so that in test environment bidding can be done on behalf of suppliers (In real time scenario participants invited over Ariba network will use their credentials to access scheduled event and participate in bidding)
After selecting appropriate forward auction template and executing create, event organizer will get next screen, pre- configured best in class process /template to configure multiple parameters, here my emphasis is to explain significance of mandatory parameters only, other parameters are simple in nature and event organizer/participants can click symbol i (small i in circle),next to attributes to get context/meaning on the same screen menu.
Rules:
Timing Rules:
Bidding start time: Date & time for scheduling auction event.
Here, lot implies content may have single item or combinations of multiple items for which bidding is planned.Business process knowledge clubbed with fair know how of market and back ground of market participants plays very important role to decide duration of event, (shorter duration avoids cartel formation among participants).
When overtime is enabled, any bid received too close to the end of the bidding period extends the bidding period. Overtime gives participants additional time to respond to late bids of other participants. It benefits the buyer to allow other participants to further improve their bids. The event owner can specify how close the bid has to be to the end and how long the overtime period lasts. When overtime is enabled, there can be an unlimited number of overtime periods.
In our use case we have considered auction running time of 10 minutes, if any supplier bids in last one minute, say 9.01 minute to 9.59 minute, this rule will get activated.
4.Start overtime if bid submitted within (minutes): 1 minute is considered in our use case after bid duration of 10 minute.
If the rank is set to 1, then only a new lead bid can trigger overtime. If it is set to 2, then a new bid ranked first or second can trigger overtime. If set to 3, then a new third, second, or first-place bid triggers an over time (and so on). Higher ranks are allowed.
There are two situations where this rule applies:
Purpose of setting a rank is to avoid starting an overtime for bids that are so far off the lead that there is no need to give other participants additional time to respond.
The recommended settings to trigger overtime are:
Rank 3 for events, where participants have no market feedback and need more time to “find” first place.
Best practice: Although overtime rule provides cushion to participants with their leading bids, event organizer to educate and make aware to participants to bid their best in reasonable time of event duration, sometime system latency (traffic over web or internet) may take little more time to get bid submitted. Due to this last minute bid submission and infrastructure delay, potential business goes away to competitors.
After configuring mandatory timing rule, event organizer to submit next button; after defining team and participants (buyers) to be invited. After clicking next, content tab for line item/lot will appear, again few mandatory attributes like bid increment & buffers to be configured.
In our use case we have assumed following:
Floor price or starting price as USD 100.
Price configuration details:
After start of bidding, buyer 1 submit his first bid, Say USD 100 (floor or starting price only)
Screenshot of buyer 1 dashboard:
We can clearly observe bid increment of USD 5 is appearing,Leading bid and rank is also displayed on the bidding console.Bid history is also recorded with time stamp.
After sometime, buyer 1 plans to submit revised bid, Say USD 104.99, and Submit bids, System does not accept and pop up error message with suggestion.
Here, Bid increment is enabled for USD 5 hence any bid equal or more than USD 5 will be accepted by system (Concept of Bid Increment). Buyer 1 revises his bid to USD 105 and resubmit, System accepts the bid.
By now, we have clear understanding of bid increment/decrement( (in case of reverse auction) attribute
Now buyer 2 observe his bid console & leading bid amount, say buyer 2 submits his first bid as USD 105, System does not allow and throw warning message like: This error warning is due to configuration of front and back buffer of amount USD 1 on leading bid (USD 105).
Now Buyer 2 revised his bid once again and this time on higher side, Say this time bids USD 105.99, again system generate warning message , as increased buffer amount is USD 0.99 is lesser than configured front buffer of USD 1.
If buyer 2 wants to take a lead in event, needs to bid minimum USD 106 (Or to overcome front buffer configuration like leading bid USD 105+front buffer of 1 USD;Totalling USD 106)
Buyer 2 revised his bid to 104.01, system does not allow.As back buffer is USD .99 which lesser against configured back buffer amount of USD 1.
Now assume Buyer 2 further revised his bid and submits his first bid at USD 104 (Floor price is USD 100 and buyer 1 first bid was USD 100.System accepts his bid of USD 104).
Here we can clearly observe, leading bid of buyer 1 is USD 105 and submitted bid by buyer 2 is USD 104 hence rank of buyer 2 bid is appearing 2.
Buyer 2 further revised his bid to take lead, say USD 109 (earlier bid was at 104+bid increment amount of USD 5, hence second bid at USD 109 at last minute)
Overtime of 1 minute added , we can observe in seller’s dashboard in Log Tab.
System already triggered overtime to accommodate last minute bidding by buyer 2.Now buyer 1 has option to revise his bid or improve his bid to get auction continue.In our use case, buyer 1 does not improve his earlier bid hence event ended after one minute of overtime.
If any of the buyer participant continue to bid in last minute, N number of overtime can trigger.
Example of multiple overtime trigger (Two times overtime,log from different event)
Best Practice: Event organizer to educate & train buyers regarding bid increment and buffer functionalities so that participants do not struggle during bidding process. They can keep their computation sheet handy offline and bid appropriately to get auction awarded. Buyers to consider submission of their first bid very seriously, as after submission, bid increment, buffer comes into picture and make job little tricky for buyers.
Apart from carefully configuring mandatory attributes, few more aspects of auction event need to address by event owner like:
Look forward to your views.
These templates are configured considering best practices of sourcing and to suites to most of the industry or business requirements, however, to make configuration tasks simpler, Ariba has identified few mandatory attributes in auction template. Event owner can configure only these and execute successful event. Apart from solution (template),event owner needs to understand significance of these mandatory attributes in connection with business processes.
In my earlier blogs, I have explained about how to create different type of auctions with the help of use cases, here,I am detailing out configuration of mandatory attributes for successful completion of auction event. User actions and system response/action in line with configured mandatory parameters are captured in table below.
Bid history (participants & system actions) of a completed forward auction event:
| Participant | Time | Rank | Action | System action | Remarks |
| System | 10 Minute | Event opened for bid | Event duration configured for 10 minutes. | ||
| Buyer-1 | 3rd Minute | Rank-1 | Opening first bid at USD 100 | System accept first bid | |
| Buyer-1 | 4th Minute | Rank-1 | 104.99 | System does not allow | Violation of bid increment configuration. |
| Buyer-1 | 5th Minute | Rank-1 | Second bid at USD 105 | System accept second bid | As per bid increment equal or more than USD 5 with respect to first bid. |
| Buer-2 | 7th Minute | Attempt to bid at USD105.99 | System does not allow | Violation of front buffer configuration. Lead bid at rank 1 have 1 USD front buffer (must be equal or more than USD 106). | |
| Buyer-2 | 7.5th Minute | Attempt to bid at USD104.01 | System does not allow | Violation of back buffer configuration. Lead bid at rank 1 have 1 USD back buffer (must be equal or less than USD 104). | |
| Buyer-2 | 8th Minute | Rank-2 | Bid at USD104 | System accept first bid | Against floor price of USD 100, starting bid is at USD104. |
| Buyer-2 | Last Minute | Rank-1 | Bid at USD109 | System accept second bid | USD104+5(bid increment)= USD105.Last minute bidding triggers overtime ,addition of 1 more minute to event |
| Buyer-1 | No action further | System ends event | Auction move to pending selection status (Supplier to be selected for awarding) |
Let’s understand significance of above mandatory attributes (Event duration, bid increment, overtime, rank, front and reverse buffer) with the help of configuration of forward auction event in Ariba sourcing module.
After creating sourcing project, event owner to select first, event type under drop down menu(one of the prerequisite) to proceed further, for our use case we have selected “forward auction”.
Once event owner select applicable event, system automatically picks pre -configured templates & display appropriate templates.
Select a Template:
Surrogate bidding is enabled at template level by Ariba administrator so that in test environment bidding can be done on behalf of suppliers (In real time scenario participants invited over Ariba network will use their credentials to access scheduled event and participate in bidding)
After selecting appropriate forward auction template and executing create, event organizer will get next screen, pre- configured best in class process /template to configure multiple parameters, here my emphasis is to explain significance of mandatory parameters only, other parameters are simple in nature and event organizer/participants can click symbol i (small i in circle),next to attributes to get context/meaning on the same screen menu.
Rules:
Timing Rules:
Bidding start time: Date & time for scheduling auction event.- Running time for the first lot: Event Organizer to decide appropriate duration for the auction event.
Here, lot implies content may have single item or combinations of multiple items for which bidding is planned.Business process knowledge clubbed with fair know how of market and back ground of market participants plays very important role to decide duration of event, (shorter duration avoids cartel formation among participants).
- Bid rank that triggers overtime:
When overtime is enabled, any bid received too close to the end of the bidding period extends the bidding period. Overtime gives participants additional time to respond to late bids of other participants. It benefits the buyer to allow other participants to further improve their bids. The event owner can specify how close the bid has to be to the end and how long the overtime period lasts. When overtime is enabled, there can be an unlimited number of overtime periods.
In our use case we have considered auction running time of 10 minutes, if any supplier bids in last one minute, say 9.01 minute to 9.59 minute, this rule will get activated.
4.Start overtime if bid submitted within (minutes): 1 minute is considered in our use case after bid duration of 10 minute.
- Overtime period (minutes): Additional 1 minute will be added to duration and in turn other participants get chance to review their bid and have option to improve further.
If the rank is set to 1, then only a new lead bid can trigger overtime. If it is set to 2, then a new bid ranked first or second can trigger overtime. If set to 3, then a new third, second, or first-place bid triggers an over time (and so on). Higher ranks are allowed.
There are two situations where this rule applies:
- Someone who was not in first, second, or third place places a bid good enough to move them into first, second, or third place. Or in other words, in last one minute new participant jumps into auction with leading bid (till now not bidded or far away from leading bids from first three suppliers).Here, new supplier was understanding behavior or bidding range of participants & submits his very aggressive bid in last minute , to outplace first three suppliers.
- One of the bidders currently in first, second, or third place places a new bid. This bid need not result in the bidder changing place (First three are competing for the business).
Purpose of setting a rank is to avoid starting an overtime for bids that are so far off the lead that there is no need to give other participants additional time to respond.
The recommended settings to trigger overtime are:
- Rank 1 for open events where participants can see the lead bid and there is no guesswork needed to find first place.
Rank 3 for events, where participants have no market feedback and need more time to “find” first place.
Best practice: Although overtime rule provides cushion to participants with their leading bids, event organizer to educate and make aware to participants to bid their best in reasonable time of event duration, sometime system latency (traffic over web or internet) may take little more time to get bid submitted. Due to this last minute bid submission and infrastructure delay, potential business goes away to competitors.
After configuring mandatory timing rule, event organizer to submit next button; after defining team and participants (buyers) to be invited. After clicking next, content tab for line item/lot will appear, again few mandatory attributes like bid increment & buffers to be configured.
In our use case we have assumed following:
Floor price or starting price as USD 100.
- A-Incremental bid is USD 5.
- B-Protect the lead bid with front buffer of USD 1
- C- Protect the lead bid with back buffer of USD 1
Price configuration details:
After start of bidding, buyer 1 submit his first bid, Say USD 100 (floor or starting price only)
Screenshot of buyer 1 dashboard:
We can clearly observe bid increment of USD 5 is appearing,Leading bid and rank is also displayed on the bidding console.Bid history is also recorded with time stamp.
After sometime, buyer 1 plans to submit revised bid, Say USD 104.99, and Submit bids, System does not accept and pop up error message with suggestion.
Here, Bid increment is enabled for USD 5 hence any bid equal or more than USD 5 will be accepted by system (Concept of Bid Increment). Buyer 1 revises his bid to USD 105 and resubmit, System accepts the bid.
By now, we have clear understanding of bid increment/decrement( (in case of reverse auction) attribute
Now buyer 2 observe his bid console & leading bid amount, say buyer 2 submits his first bid as USD 105, System does not allow and throw warning message like: This error warning is due to configuration of front and back buffer of amount USD 1 on leading bid (USD 105).
Now Buyer 2 revised his bid once again and this time on higher side, Say this time bids USD 105.99, again system generate warning message , as increased buffer amount is USD 0.99 is lesser than configured front buffer of USD 1.
If buyer 2 wants to take a lead in event, needs to bid minimum USD 106 (Or to overcome front buffer configuration like leading bid USD 105+front buffer of 1 USD;Totalling USD 106)
Buyer 2 revised his bid to 104.01, system does not allow.As back buffer is USD .99 which lesser against configured back buffer amount of USD 1.
Now assume Buyer 2 further revised his bid and submits his first bid at USD 104 (Floor price is USD 100 and buyer 1 first bid was USD 100.System accepts his bid of USD 104).
Here we can clearly observe, leading bid of buyer 1 is USD 105 and submitted bid by buyer 2 is USD 104 hence rank of buyer 2 bid is appearing 2.
Buyer 2 further revised his bid to take lead, say USD 109 (earlier bid was at 104+bid increment amount of USD 5, hence second bid at USD 109 at last minute)
Overtime of 1 minute added , we can observe in seller’s dashboard in Log Tab.
System already triggered overtime to accommodate last minute bidding by buyer 2.Now buyer 1 has option to revise his bid or improve his bid to get auction continue.In our use case, buyer 1 does not improve his earlier bid hence event ended after one minute of overtime.
If any of the buyer participant continue to bid in last minute, N number of overtime can trigger.
Example of multiple overtime trigger (Two times overtime,log from different event)
Best Practice: Event organizer to educate & train buyers regarding bid increment and buffer functionalities so that participants do not struggle during bidding process. They can keep their computation sheet handy offline and bid appropriately to get auction awarded. Buyers to consider submission of their first bid very seriously, as after submission, bid increment, buffer comes into picture and make job little tricky for buyers.
Apart from carefully configuring mandatory attributes, few more aspects of auction event need to address by event owner like:
- Getting things right first time from participants (mock auction sessions with participants before actual auction event).
- Best value against total cost, rather than cheapest price or unit price for the awarding.
- Clear communication of specifications, other terms and conditions or what is required? To avoid ambiguity among participants, consolidated response of participants’ queries can be shared with each participant before start of the event.
- Infrastructural support from event organizing team (Technology and process support during auction)
- If participants are from a different countries and time zone, timing chosen to run the auction is convenient to those participants.
Look forward to your views.
- SAP Managed Tags:
3 Comments
