/
Allocation

Allocation

Owned by Amelia Witka (Unlicensed)
Last updated: Apr 12, 2021

Planning Scenario Determination

It is possible to determine the planning scenario base on the order type and hierarchy data.


Planning scenario determination (1)


Maintain your order types and planning scenarios.


Planning scenario determination (2)


Overloading Profile Definition and Determination


In the definition of the Overloading Profile we can specify in addition, if the resources are supposed (because of the Overloading Profile) to work during weekends or holidays (additional checkboxes in the definition of the Overloading Profile),

In the definition of SRS Document Type we can specify when (if) the Overloading Profile is to be cleared in the SRS Demand data. We can also specify when (under which circumstances) the Overloading Profile should be determined.


Table below describes (using the use cases approach) what are the new functions:

ActivityResult

We prepare the following workers:

  • KAM_WORKER01 – available 100 %,
  • KAM_WORKER02 – available 50 %,
  • KAM_WORKER03 – available 100 %.

 So far we do not do anything with Overloading Profile.

Please notice, that in total we have 250 % of the resource Worker *.

We setup the procedure to perform the allocation on the Worker * level.

We create the first order.

We have in average 83% of Worker *:

 

(calculated as (100% + 50% + 100%) / 3 = 83%).

 The resource Worker * has been consumed with the percentage of 83%. Thereby the task, which normally takes 2 h now is assigned for 2 h 30 min:

Note:

Please notice, that this is a change of the logic compared to the previous releases. Previously the logic was “We have 250%, so it means, that we have at least 100%, so we consume 100%). Since 19.11 we consume the average availability, in this case 83%.

We create next 2 orders

All 3 order have been allocated in the same way:

We have consumed fully the capacity of Worker * in the time 08:00 – 10:30.

We deallocate previous orders.

We change the availability of KAM_WORKER01 from 100% to 150%.

We switch the planning procedure – we allocate on the given Worker level (not on the Worker * level).

We create the first order.

KAM_WORKER01 wins – because his performance is 150%, he will do the 2h job in 1 h 30 min (08:00 – 09:30):

We create next order.

KAM_WORKER03 wins – he will do the job in 2 h (08:00 – 10:00):

We create next order.

KAM_WORKER01 wins – he will do the job in 1 h 30 min (09:30 – 11:00):

Please notice, that KAM_WORKER03 is still available and he is still without work – because of his low performance.

We create next order.

Finally KAM_WORKER02 gets something to do.

Because he is available at 50%, he needs 4 hours to do the job, which normally needs 2 h.

He has received this job because there is nobody, who could do this job faster.

 

The allocations are now the following:

 

We deallocate all the previous orders.

We create next order.

We set KAM_WORKER03 as the preferred resource.

We allocate it.


KAM_WORKER03 gets the job (although KAM_WORKER01 would be faster).

The duration of this allocation is 2 h:

We change the allocation to KAM_WORKER01

(we use “with rescheduling” option).

KAM_WORKER01 gets the job, the duration is changed automatically to 1h 30 min:

 

(if we used drag & drop to KAM_WORKER02, the duration would be changed to 4 h)

We start to play with Overloading Profile.

We configure the determination and clearing of Working Profile.


We use new fields of SRS Order Type:


We specify the Overloading Profile determination to take place always, whenever the SRS Demand gets allocated. The Overloading Profile will be redetermined as well each time, when the SRS Demand gets allocated (regardless if the Demand is already allocated or the Overloading Profile has already been determined (set)).

We can have the following values, as far as the determination is concerned:


We specify the Overloading Profile clearing to take place, whenever the demand gets deallocated.

We can have the following values, as far as the clearing is concerned:


 The Overloading Profile is determined using Lean Condition technique. The following fields are taken into consideration:

Field - Description

CAPPL - Calling Application

HIERARCHY_ID - Hierarchy ID

BUKRS - Company Code

VKORG - Sales Organization

WERKS - Plant

VTWEG - Distribution Channel

SPART - Division

WPO_DOC_TYPE - Document Type

ORDER_TYPE - Order Type

PLAN_SCENARIO - Plan Scenario

PARTNER - Business Partner Number

CUSTOMER - Customer Number

MAKE_CODE - Make Code

MODEL_CODE - Model Code

DEMAND_TYPE - Demand Type


  • The BADI /DBME/WMA_ORDER is enhanced to allow the customer to influence the Overloading Profile determination:

ON_OVERLOAD_PROF_DET_01 - Determine the Overloading Profile

ON_OVERLOAD_PROF_DET_02 - Influence Overloading Profile Determination – change Lean Condition Communication Structure fields

We configure the definition of the Overloading Profile.

We use the area menu /DBME/WMA_MENU_USER:


We configure the determination of the Overloading Profile.

We use the area menu /DBME/WMA_MENU_USER:


We change the allocation to force the worker to work before his working hours.

We use drag & drop, we drop the allocation on KAM_WORKER03 on 01:00 in the night:



Result:

Please notice, that according to working hours of KAM_WORKER03 the allocation should start at 08:00. But, as we have specified in the Overloading Profile, KAM_WORKER03 is supposed to start working 1h 30min earlier, thereby the allocation starts from 06:30.

Please notice the indicator (K2) in the task description .

It is retrieved from:


Fill free to create any indicator you want.


Once the allocation has been performed, the Overloading Profile has been stored in the new Demand DB field:



We change the allocation to force the worker to work after his working hours.

We drop the allocation to 16:00:


KAM_WORKER03 works till 17:00 (according to his working model). Because of the Overloading Profile he works now till 18:00, thereby he still manages to do the job.

We drop to allocation to 16:15:

If we force the allocation to take place 15 minutes later, it does not fit any longer – in this case the 1 h 45 min is scheduled on that day and the remaining 15 min is scheduled on the next day:


We force the worker to work during his Working Model Breaks as well.

We configure the Overloading Profile not to use Working Model Breaks (let the Working Model Breaks be kept):


We drop the allocation to 11:30. The allocation is automatically split – the break between 12:00 and 13:00 is considered:


However when we change the Overloading Profile definition to force the worker to work during breaks as well:


the allocation is created also during the Working Model Breaks as well.


The same kind of logic will be applied, when we try to create allocation during holiday or day-off.

Use Efficiency Factor.

So far we didn’t provide the Efficiency Factor in the Overloading Profile Definition.

We set the Efficiency Factor to 125%:


When doing the next allocation, the allocation duration is shortened to 1h 45 min:


And the worker consumption is set to 125%:


Resource Consumption (125%) is calculated as Resource Availability (100%) multiplied by Effectiveness Factor (125%).

When we drop the allocation on KAM_WORKER02, the duration is 3h 15 min:


Resource Consumption (63%) is calculated as Resource Availability (50%) multiplied by Effectiveness Factor (125%).

When we drop the allocation on KAM_WORKER01, the duration is 1h 15 min:


Resource Consumption (188%) is calculated as Resource Availability (150%) multiplied by Effectiveness Factor (125%).