The LINQ language enables many actions to
support the creation of a single information asset. This needs to be used with
caution – the description of the action frequency and duration, associated with
who or what performs the action becomes a critical element of the thought
process needed to utilise this capability.
There are times when it is legitimate to show two actions
creating the same piece of information and there are times when it is not.
Here are some thought processes to consider, followed by
some scenarios to help you consider your own situation.
1. Two different actions cannot occur at the
same time to create the same piece of information. If the action descriptions
are different, it means that there are 2 separate information flows at work,
and there will be an action taking place which will combine information to
create the necessary asset. If your actions are described differently, with
different people or different systems performing them, they should not be
linked to the same information output. For example:
In this Information Supply Chain we see that
we have two ways that a customer can get themselves signed up for a loyalty
card:
·Entering their details on a website
·Call in and someone manually enters their
details for them
We drew two information supply chains in
LINQ, and now we try to connect an action (add preferred customer) to the
preferred customer record from the manual signup chain. It’s just two different
ways to create the same information and LINQ will let us do it!
But is it really possible that these two
different actions produce the same piece of information? If that was true, you
would have two separate and conflicting customer records for the same person.
Which one is the right one? It’s really unlikely the real system does it this
way, and if it does there is going to be a lot of trouble with duplicated
information and processes!
Somewhere, there is likely to be a merging,
updating, or reconciliation action that makes sure there is only one correct
customer record. After a bit more digging we find out it actually looks like
the chain below. The 'add or update customer record' action ensures there is
only one customer record.
When you come across a situation
like this, you need to ensure that you are capturing what actually happens in
your organisation:
·Look deeper and find out if there is really
duplication
·Locate the extra information supply chain that
links and reconciles the two
In this scenario, the Information Supply Chains
merge at the Action “Add or update customer record”; with potentially many
individual pieces of Information being manipulated to create the required
information entity which is then used for the remainder of the Supply Chain:
2. The same action can be performed by
different people in order to create the information asset. If you are recording
actions which have the same name, but the people performing the action are
different, their burden cost is different and how long and how often they
perform the action is different, then the new LINQ connection from many actions
to one information asset is legitimate. For example:
In this scenario, A legal company allows Partners and
Secretaries to record time with clients into the Time Management System against
the client record. The Partners ($500 p/h) and the Secretaries ($40 p/h) have different
hourly rates but the action that is performed and the location of the
information that is created is the same – there is an 80/20 split between the
Secretary (800 per annum) and the Partner (200 per annum) undertaking the time
recording. The Partners also take longer than the Secretaries to perform the
same task.
In this situation, the action is
the same, it is just performed by different people at different frequencies.
The system associated with the information is also the same, the Time Management
system, and the information is the same, the client record.
In this circumstance having 2
parallel ISC flows is not necessary. The new rules enable the 2 actions, which
record the differing durations and frequencies to be linked to the same
information output. Connecting two actions to one information node isn't possible in LINQ, but seems like something that should be possible.
3. Consider this Information Supply Chain for
multi-channel client engagement.
Our customer can interact with our
organisation in 3 ways; walk-in, over the phone or via email. Customer Services
are responsible for the initial engagement via phone or email and the Reception
Team takes responsibility for walk-ins. Both teams use the CRM to log the
interaction so that the client record is kept up to date.
The walk-in engagement is the longest.
Documenting the conversation takes time; but the result is that the client
engagement record is up to date. Phone calls are also lengthy, but again, the
result is that the client engagement record is up to date. Emails are quicker;
the initial email and the response are tagged to the client record in the CRM
by the Customer Service representative.
The action that they all take is to Log the
enquiry into the CRM and the result of the action is that the Client record in
the CRM is updated. How long each team takes is different – this is recorded
against each action – but the result of the action is the updates information
asset in the CRM.
In this scenario, it is entirely legitimate
to link the 3 actions that are the same, with their corresponding frequencies
and durations to the information asset that is created by the update.
Neil Calvert
The LINQ language enables many actions to support the creation of a single information asset. This needs to be used with caution – the description of the action frequency and duration, associated with who or what performs the action becomes a critical element of the thought process needed to utilise this capability.
There are times when it is legitimate to show two actions creating the same piece of information and there are times when it is not.
Here are some thought processes to consider, followed by some scenarios to help you consider your own situation.
1. Two different actions cannot occur at the same time to create the same piece of information. If the action descriptions are different, it means that there are 2 separate information flows at work, and there will be an action taking place which will combine information to create the necessary asset. If your actions are described differently, with different people or different systems performing them, they should not be linked to the same information output. For example:
In this Information Supply Chain we see that we have two ways that a customer can get themselves signed up for a loyalty card:
· Entering their details on a website
· Call in and someone manually enters their details for them
We drew two information supply chains in LINQ, and now we try to connect an action (add preferred customer) to the preferred customer record from the manual signup chain. It’s just two different ways to create the same information and LINQ will let us do it!
But is it really possible that these two different actions produce the same piece of information? If that was true, you would have two separate and conflicting customer records for the same person. Which one is the right one? It’s really unlikely the real system does it this way, and if it does there is going to be a lot of trouble with duplicated information and processes!
Somewhere, there is likely to be a merging, updating, or reconciliation action that makes sure there is only one correct customer record. After a bit more digging we find out it actually looks like the chain below. The 'add or update customer record' action ensures there is only one customer record.
When you come across a situation like this, you need to ensure that you are capturing what actually happens in your organisation:
· Look deeper and find out if there is really duplication
· Locate the extra information supply chain that links and reconciles the two
In this scenario, the Information Supply Chains merge at the Action “Add or update customer record”; with potentially many individual pieces of Information being manipulated to create the required information entity which is then used for the remainder of the Supply Chain:
2. The same action can be performed by different people in order to create the information asset. If you are recording actions which have the same name, but the people performing the action are different, their burden cost is different and how long and how often they perform the action is different, then the new LINQ connection from many actions to one information asset is legitimate. For example:
In this scenario, A legal company allows Partners and Secretaries to record time with clients into the Time Management System against the client record. The Partners ($500 p/h) and the Secretaries ($40 p/h) have different hourly rates but the action that is performed and the location of the information that is created is the same – there is an 80/20 split between the Secretary (800 per annum) and the Partner (200 per annum) undertaking the time recording. The Partners also take longer than the Secretaries to perform the same task.
In this situation, the action is the same, it is just performed by different people at different frequencies. The system associated with the information is also the same, the Time Management system, and the information is the same, the client record.
In this circumstance having 2 parallel ISC flows is not necessary. The new rules enable the 2 actions, which record the differing durations and frequencies to be linked to the same information output. Connecting two actions to one information node isn't possible in LINQ, but seems like something that should be possible.
3. Consider this Information Supply Chain for multi-channel client engagement.
Our customer can interact with our organisation in 3 ways; walk-in, over the phone or via email. Customer Services are responsible for the initial engagement via phone or email and the Reception Team takes responsibility for walk-ins. Both teams use the CRM to log the interaction so that the client record is kept up to date.
The walk-in engagement is the longest. Documenting the conversation takes time; but the result is that the client engagement record is up to date. Phone calls are also lengthy, but again, the result is that the client engagement record is up to date. Emails are quicker; the initial email and the response are tagged to the client record in the CRM by the Customer Service representative.
The action that they all take is to Log the enquiry into the CRM and the result of the action is that the Client record in the CRM is updated. How long each team takes is different – this is recorded against each action – but the result of the action is the updates information asset in the CRM.
In this scenario, it is entirely legitimate to link the 3 actions that are the same, with their corresponding frequencies and durations to the information asset that is created by the update.