Enron Mail

From:sally.beck@enron.com
To:richard.sage@enron.com
Subject:Re: CommodityLogic.com
Cc:
Bcc:
Date:Fri, 11 Aug 2000 04:27:00 -0700 (PDT)

Thanks for copying me on this. It is interesting to see your thoughts. I
suggested that Tom visit with both you and Mike while he was in London. I
told Mike that I support many of the ideas of CommodityLogic. However, I
also told him about my two dark-side fears: (1) that IT resources reporting
to Networks would make it even more difficult to get the attention on
projects that we need, and (2) taken to the extreme, that this concept would
disinsent operations personnel from coming up with creative solutions to
managing the growth of the business if all good ideas are swept away to this
special team for them to handle. Part of the fun in operations is improving
things, and I would hate to rob some of our most knowledgeable people of the
chance to implement creative business solutions.




Richard Sage
08/11/2000 10:10 AM
To: Mike Jordan/LON/ECT@ECT
cc: Sally Beck/HOU/ECT@ECT, Steve Whitaker/LON/ECT@ECT
Subject: 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 Power99 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