commoditylogic . com mike ,
further to our conversation , here are some of the things i thought of while
speaking with tom gros . there are definitely some challenges we have to
overcome to make the hub idea within commoditylogic . com as successful as
enrononline rather than have it turn out like sitara .
i won ' t repeat thoughts about how we split cl from enron , but let ' s put
ourselves in the shoes of somebody external for whom this was presented as a
potential solution . well , that ' s an easy decision , somebody else is doing the
hard work , and not charging us very much for it . so sign - up , but don ' t rely
on anything until we see everything working .
handling counterparties not using the system
the challenge here is that the final solution world with overybody using the
hub is wonderful , but until everybody is using the hub , we have to keep other
procedures and systems going , which stretches resources , development , it
support and user . this was why we decided to delay getting bolero - the
concept is wonderful , but the value to any user is very dependent on everyone
else one trades with using the system . this is classic chicken and egg . tom
has a vision of cl providing the staff to handle this . this is taking us
closer to an outsource - to - andersen - consulting model which is certainly
achievable , although not quite such an easy sell .
how much resource is left
the latest project always tends to attract the most imaginative people , who
are therefore not available for keeping everything else going and moving
onwards . how about if we accept that such resource is dedicated to cl , and
then review what is left in the remaining environment . does it mean we hold
off doing anything ? if we do then increasing volume means that we might end
up incurring costs for massive numbers of people ! we should go through
costing for " what happens if we completely stop development of x project ? " .
if that shows one would need 200 clerks for 3 years until something else
comes along then it may be cheaper than developing , but i hope in most cases
it is not !
start small to prove concept
e . g . first application in april 2001 only covers 20 fields
this is excellent , and we needn ' t shout it too loud to investors in cl , but
for our internal back office costing we need to acknowledge that it will be
years before we can switch off many internal systems .
we might limit the payback period on projects not part of this strategy to 3
years out ?
include european aspects from the beginning
this really isn ' t very difficult so long as one has some long - on - common - sense
europeans ( not just brits ) involved in both specification and development
from the beginning , but an as example of how not to do it , look at enpower
which took a year to allow just for currencies etc !
80 - 20 rule for types of transaction
eol has shown the benefits of focussing on simpler products first .
once we have robust warehouses for collecting accounting ( dtl ) and risk
( risktrac ? ) numbers then we can think about having vanilla products on stp ,
and yet - to - become - vanilla products on explicitly different , manual
approaches . until that time , we have a strong desire to include as many
different prodcuts as possible for a given commodity in one system , which
makes separating vanillas from others more complicated and costly ( think of
certain deals in power 99 which are approximations of the actual deals , and
manually tweaked every so often )
testing
tom ' s first thought is that we could leverage initial users ( who would not
pay ) to do much of the testing .
eol clearly got its testing done , but other experience shows that in order to
have anything which saves time one really does need to do all the different
phases - component , system , integration , end - to - end , and then user - acceptance .
eol saw confidentiality as an issue and was therefore unable to use many
external users early in the process . it did have massive
resource - commandability and so obtained input from many traders . do the
support functions have sufficient slack that they will be able to provide the
same sort of user attention ? given how often i hear " short people " , that
strikes me as something which in london would require significant additional
resource , even after mg is absorbed .
what else did you come up with ?
richard
commoditylogic . com
mike ,
further to our conversation , here are some of the things i thought of while
speaking with tom gros . there are definitely some challenges we have to
overcome to make the hub idea within commoditylogic . com as successful as
enrononline rather than have it turn out like sitara .
i won ' t repeat thoughts about how we split cl from enron , but let ' s put
ourselves in the shoes of somebody external for whom this was presented as a
potential solution . well , that ' s an easy decision , somebody else is doing the
hard work , and not charging us very much for it . so sign - up , but don ' t rely
on anything until we see everything working .
handling counterparties not using the system
the challenge here is that the final solution world with overybody using the
hub is wonderful , but until everybody is using the hub , we have to keep other
procedures and systems going , which stretches resources , development , it
support and user . this was why we decided to delay getting bolero - the
concept is wonderful , but the value to any user is very dependent on everyone
else one trades with using the system . this is classic chicken and egg . tom
has a vision of cl providing the staff to handle this . this is taking us
closer to an outsource - to - andersen - consulting model which is certainly
achievable , although not quite such an easy sell .
how much resource is left
the latest project always tends to attract the most imaginative people , who
are therefore not available for keeping everything else going and moving
onwards . how about if we accept that such resource is dedicated to cl , and
then review what is left in the remaining environment . does it mean we hold
off doing anything ? if we do then increasing volume means that we might end
up incurring costs for massive numbers of people ! we should go through
costing for " what happens if we completely stop development of x project ? " .
if that shows one would need 200 clerks for 3 years until something else
comes along then it may be cheaper than developing , but i hope in most cases
it is not !
start small to prove concept
e . g . first application in april 2001 only covers 20 fields
this is excellent , and we needn ' t shout it too loud to investors in cl , but
for our internal back office costing we need to acknowledge that it will be
years before we can switch off many internal systems .
we might limit the payback period on projects not part of this strategy to 3
years out ?
include european aspects from the beginning
this really isn ' t very difficult so long as one has some long - on - common - sense
europeans ( not just brits ) involved in both specification and development
from the beginning , but an as example of how not to do it , look at enpower
which took a year to allow just for currencies etc !
80 - 20 rule for types of transaction
eol has shown the benefits of focussing on simpler products first .
once we have robust warehouses for collecting accounting ( dtl ) and risk
( risktrac ? ) numbers then we can think about having vanilla products on stp ,
and yet - to - become - vanilla products on explicitly different , manual
approaches . until that time , we have a strong desire to include as many
different prodcuts as possible for a given commodity in one system , which
makes separating vanillas from others more complicated and costly ( think of
certain deals in power 99 which are approximations of the actual deals , and
manually tweaked every so often )
testing
tom ' s first thought is that we could leverage initial users ( who would not
pay ) to do much of the testing .
eol clearly got its testing done , but other experience shows that in order to
have anything which saves time one really does need to do all the different
phases - component , system , integration , end - to - end , and then user - acceptance .
eol saw confidentiality as an issue and was therefore unable to use many
external users early in the process . it did have massive
resource - commandability and so obtained input from many traders . do the
support functions have sufficient slack that they will be able to provide the
same sort of user attention ? given how often i hear " short people " , that
strikes me as something which in london would require significant additional
resource , even after mg is absorbed .
what else did you come up with ?
richard