In LINQ, each Action and People pairing represents an activity for a person (or team or role) during their day/month/year - think of it as a slice of their time needed to perform the action.
The LINQ model enables many people to be linked to a
single action. This allows the modelling of actions such as meetings, which are
attended by many people who have a different burdened rate, but the action, the
meeting, is a standard duration.
Scenario 1: Adam, Bob, and Cathy
have a meeting together once a week, which is always the same duration, to
produce design scenarios and use cases. Adam models this situation in LINQ
after the meeting, and he connects three People nodes to one Action node. He
can adjust the duration of the Action (the meeting) and individually set the
hourly rate for each person. The cost of the meeting can be generated from
these values.
To
support this scenario, we now allow multiple People nodes to be connected to a
single Action node. They share a common frequency and duration. Their hourly
rates are added together and then multiplied by the frequency and duration to
calculate the cost of the action. This would typically use the 'Person' type of
People node.
Adam has an hourly cost of $200, Bob $100 and Cathy
$300. These costs are recorded against each individual Person node.
The action they perform, a meeting of duration 2
hours, once a week, provides an
annualised meeting cost of $62,400.
Scenario 2: There is a call
centre 'all hands' meeting which is led by the call centre manager once a week,
and also has the operations manager present. This meeting generates specific
information in terms of targets for the week.
This is a hybrid scenario that is possible. Let's
say that once a week, there is a call centre 'all hands' meeting which is led
by the call centre manager and also has the operations manager present. This
meeting generates specific information in terms of targets for the week (for
example) In this scenario, the 'all hands meeting' action node generates a
'weekly target' piece of information. The meeting happens once a week and lasts
30 minutes. The Call Centre Manager is paid $50 an hour, the Operations Manager
is paid $100 an hour and the 20 customer service reps are paid an average of
$20 an hour. In this example, the annual cost is (26 hours (a year) x
($50+$100+(20x$20))... a total of 26 x $550 = $14,300.
In other scenarios, where the actions do NOT share a
common frequency and duration, then the actions should not be connected
together like this... instead separate Action nodes should be used, either in
serial if the sequence is defined or in parallel if the sequence doesn't matter.
Care does need to be taken when considering connecting more
than one person to an action. The action must describe the duration and
frequency for everyone involved. If durations and frequencies could be
different based on the system used to support the action by the person, the
person’s skill level affecting the time they need to complete the action, etc,
then separate actions nodes will be needed.
Consider this for multi-channel client engagement.
The final action – Log the enquiry into CRM is performed by
both the Customer Services and Reception teams. This is represented by both
teams being linked to the same action. Reading this diagram, we would be led to
believe that this is an action which takes the same amount of time every time
it is performed, and that we do not care about any potential split in the
number of occurrences of the action based on the communication channel.
The reality is probably different. It would take longer to
log a face-to-face conversation or phone call into the CRM than dealing with an
email which can simply be attached to the CRM record. In our business, we also
know that 70% of interaction is via email, 20% by phone and only 10% through
walk-in.
This shows us that we need 3 separate actions with the
correct People nodes attached to each so we can accurately describe what these
teams do and how often they do it. This sketch, which also makes use of the new
Many Actions Create One Information Asset language extension, is an accurate
reflection of our current state:
Neil Calvert
In LINQ, each Action and People pairing represents an activity for a person (or team or role) during their day/month/year - think of it as a slice of their time needed to perform the action.
The LINQ model enables many people to be linked to a single action. This allows the modelling of actions such as meetings, which are attended by many people who have a different burdened rate, but the action, the meeting, is a standard duration.
Scenario 1:
Adam, Bob, and Cathy have a meeting together once a week, which is always the same duration, to produce design scenarios and use cases. Adam models this situation in LINQ after the meeting, and he connects three People nodes to one Action node. He can adjust the duration of the Action (the meeting) and individually set the hourly rate for each person. The cost of the meeting can be generated from these values.
To support this scenario, we now allow multiple People nodes to be connected to a single Action node. They share a common frequency and duration. Their hourly rates are added together and then multiplied by the frequency and duration to calculate the cost of the action. This would typically use the 'Person' type of People node.
Adam has an hourly cost of $200, Bob $100 and Cathy $300. These costs are recorded against each individual Person node.
The action they perform, a meeting of duration 2 hours, once a week, provides an annualised meeting cost of $62,400.
Scenario 2:
There is a call centre 'all hands' meeting which is led by the call centre manager once a week, and also has the operations manager present. This meeting generates specific information in terms of targets for the week.
This is a hybrid scenario that is possible. Let's say that once a week, there is a call centre 'all hands' meeting which is led by the call centre manager and also has the operations manager present. This meeting generates specific information in terms of targets for the week (for example) In this scenario, the 'all hands meeting' action node generates a 'weekly target' piece of information. The meeting happens once a week and lasts 30 minutes. The Call Centre Manager is paid $50 an hour, the Operations Manager is paid $100 an hour and the 20 customer service reps are paid an average of $20 an hour. In this example, the annual cost is (26 hours (a year) x ($50+$100+(20x$20))... a total of 26 x $550 = $14,300.
In other scenarios, where the actions do NOT share a common frequency and duration, then the actions should not be connected together like this... instead separate Action nodes should be used, either in serial if the sequence is defined or in parallel if the sequence doesn't matter.
Care does need to be taken when considering connecting more than one person to an action. The action must describe the duration and frequency for everyone involved. If durations and frequencies could be different based on the system used to support the action by the person, the person’s skill level affecting the time they need to complete the action, etc, then separate actions nodes will be needed.
Consider this for multi-channel client engagement.
The final action – Log the enquiry into CRM is performed by both the Customer Services and Reception teams. This is represented by both teams being linked to the same action. Reading this diagram, we would be led to believe that this is an action which takes the same amount of time every time it is performed, and that we do not care about any potential split in the number of occurrences of the action based on the communication channel.
The reality is probably different. It would take longer to log a face-to-face conversation or phone call into the CRM than dealing with an email which can simply be attached to the CRM record. In our business, we also know that 70% of interaction is via email, 20% by phone and only 10% through walk-in.
This shows us that we need 3 separate actions with the correct People nodes attached to each so we can accurately describe what these teams do and how often they do it. This sketch, which also makes use of the new Many Actions Create One Information Asset language extension, is an accurate reflection of our current state:
1 person likes this