Message-ID: <17347504.1075855816896.JavaMail.evans@thyme> Date: Fri, 11 Aug 2000 09:10:00 -0700 (PDT) From: richard.sage@enron.com To: mike.jordan@enron.com Subject: CommodityLogic.com Cc: sally.beck@enron.com, steve.whitaker@enron.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bcc: sally.beck@enron.com, steve.whitaker@enron.com X-From: Richard Sage X-To: Mike Jordan X-cc: Sally Beck, Steve Whitaker X-bcc: X-Folder: \Sally_Beck_Dec2000\Notes Folders\Commoditylogic X-Origin: Beck-S X-FileName: sbeck.nsf 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