Archive for June, 2008
Here are some items that popped into my google alerts recently for reverse auction:
- A lowest unique bid wins gambling site. Their press release appears to be deliberately confusing given that talks about reverse auctions, procurement auctions and e-sourcing before diving into their gambling piece. They even go so far as to claim that “The legality of low unique auctions has been proven by the American, British and the Danish governments who are all using the low unique auction concept [for awarding procurement contracts].” (No they’re not, they’re using reverse auctions – they aren’t using gambling sites)
- Forwards Dutch Auctions for mobile gear
I know some of you will consider this is just me quibbling over semantics but this is pretty important. Surely buyers need to know their auction types to be able to run effective sourcing projects. Just like they need to know their DDP from their FOB. I get really riled when people use the same term to mean completely different auction types. How many buyers would know that this auction here is not a reverse auction at all but is a forwards dutch auction?
The stories we hear about (software) product development tend to be the success stories. The guys who made it big. And a never ending analysis of “how you can be just like them”.
But very few people know precisely what combination of vision, skill, timing and luck made them a success. And fewer are able to articulate it. And personal experience tells me that I learn as much, if not more, when things go against me than when things go swimmingly well.
So I learned a lot from this post which describes a failed project and ascribes some of the failures to engineering decisions made during the product development lifecycle. The three mistakes Ari identifies that are most generally applicable to software developers are:
Mistake: Defaults Matter
Mistake: Make it Instantly Useful
Mistake: Don’t Let Technology Decide
For the record this is how I landed up at the post. Started by looking around at Max Bleyleben’s blog on Technorati. Which took me to Max Niederhofer and from there to Union Square Ventures and from there to Ari’s great post
I’ve long contended that, behind all the hype about Source To Pay systems and SRM packages and Flex interfaces and eAuction software, Excel remains one of the top 3 software tools for buyers. (The other 2 being Outlook and Google).
So I enjoyed reading this article on CFO.com all about spreadsheet worst practices and how to avoid them. Here’s how the article starts:
There’s little doubt that electronic spreadsheets are the most widely-used financial software application. But they are also the most-abused.
The article clearly struck a chord with CFO’s readership, as they published a follow up with readers’ views.
The CFO article is directed mainly at those who use Excel for number crunching, analysis and what-if planning. So the practices in the article will be of most interest to buyers who use Excel for analysis. But there are also some nuggets that you can pull out of the articles, even if you only ever use Excel for issuing RFQ templates.
The practices CFO highlights:
1. Poor segregation of data. Some people use Excel just as a super calculator. So if you look into a cell you might find the formula “=300000*1.50+158000*1.46+250000*1.20*0.95”. While it might make sense to the person doing the calculation at the time that we are looking at the total forecast spend for three different parts (300000 units at $1.50, 158000 at $1.46 and 250000 at $1.20 less a 5% discount), a formula as bare as this is not going to help explain the data 3 months down the line
2. Poor documentation of assumptions. The last part in my example formula is 250000*1.20*0.95. You could read this as 250000 parts at $1.20 with a discount of 5%. But why the discount? Does the discount always apply? Or is it some volume discount based on ordering over 200000 items?
3. Poor documentation of constraints. Don’t put one complex formula in a cell. Remember in your maths exams when you were always told to show your workings? Same applies in Excel. Better to use multiple, intermediate calculations to show how you are getting to the final result.
4. Difficulties in making changes. If we decided that we wanted to change the forecast volume for part B to 180000 then it’s not immediately straightforward to know where to update the spreadsheet
5. Now it’s here, Now it’s not. The ability to change one value in a spreadsheet and have all the relevant values re-calculated is very powerful. But it’s also easy to lose track of where you were before you started your what-if scenarios. CFO.com’s recommendation is to use different worksheets for different scenarios, with one master worksheet to summarise and compare the results of your different scenarios.
6. Presentation Ready. It’s not hard to set your spreadsheets up for printing – with headers, footers, page sizing, repeating columns and rows. But it’s often overlooked, to the annoyance of the people you are emailing your spreadsheet to.
While doing some research on various Wikis out there, I’ve found that a company called the Information Superbrand (check out the whois info here) registered the domain www.pedia.com, as well as over two hundred various ****pedia.com domain names, such as travelpedia.com or tvpedia.com. In some cases, a domain wasn’t available so they just used subdomains, for example parent.pedia.com.
Mashable doesn’t offer any viable solutions beyond “I think it sucks” and “it strikes me as wrong.” The comment string similarly doesn’t offer any analysis beyond indignation at the problem.
Wise up suckers. The only way anything will get done with this domain mess is if they become too expensive to register.
Golden Pebbles has only been going for a week or two and already it’s in the top spot at Google!
No joke. Look here.
Number 1. Numero Uno. The big kahuna.
Ok, admittedly it might have something to do with the fact that I’ve spelt “scaleability” with an “e” and most seem to spell it without the “e”. But heck. It was fun to see some traffic coming through from that search.
Last year I moved out of London and bought an electric scooter from these guys for driving the 3.5 miles between my new house and the train station.
The story so far:
1. When it first arrived it didn’t work: the batteries weren’t functional. It took a good two weeks to get it workable.
2. Finding an insurer was a mission. There’s apparently only one in the UK. They aren’t cheap.
3. Stuff just fell off the scooter. Nothing major (yet). But still I haven’t got working replacements.
4. One of the options I bought they never even delivered. Kept fobbing me off for best part of 9 months (and I didn’t have time to chase every day).
5. It was vandalised once (someone yanked an important cable out) – and the supplier expected me to be able to fix it. Heck, I don’t even own a soldering iron, let alone feel confident digging around in the bowels of the scooter.
6. Kids have sniggered at the man on the scooter … Until they realise it’s electric whereupon their sniggers are replaced by wows.
7. Fellow commuters are impressed by the electric scooter. Then they overtake me on the way home.
8. It is fun to drive a nearly silent machine. But it would be nice if it would go faster.
9. It’s nice not to need to stop and fill up with petrol (though I have no idea whether the electricity I use to charge it is cleaner, greener and/or cheaper than petrol would be).
It’s clear that this bike is still bleeding edge. It’s still the domain of enthusiast hackers. Definitely not ready for consumer prime time.
Parallels for professional buyers:
Beware of getting too far ahead of yourselves on green initiatives. Unless you have the time, inclination and executive support get too far ahead of the pack and you could struggle (1,2,3,4,5).
There is a good marketing angle (6,7).
And, heck, it might even make you feel better (8,9).
To be honest: When I look at my buying decisions at work I haven’t gone out of my way to buy greener at work. The only thing I can recall doing recently is ticking the box marked “plant a tree for every server” on a hosting deal.
One: two girls, apparently recent uni grads. They discuss catching up with a friend of theirs on Facebook. And they discuss the blog another friend of theirs used to have.
Two: a “young professional” couple. logging onto Facebook to catch up with friends.
I love the way so much technology is being more and more, well, normal.
10, 20 years ago, technology was strictly for young men with dubious hygiene skills and an aversion to sunlight and exercise. (I still remember the farting competitions held by some ABAP colleagues in their windowless office). You even got bonus management credibility points for NOT knowing how computers worked and needing someone else to type your documents for you.
But fast forward to 2008 and my 10-year old god-daughter spends a LOT of time on sites like http://www.girlsgogames.com/ while Instant Messaging their friends.
And this article on Mashable http://mashable.com/2008/03/08/girls-web-uk-us/
I find this shift very exciting. I only wish I were at school now and had the internet to help me discover the world.
A few years back we did some work with Oxford University. They were interested in how procurement auctions fitted into the bigger auction picture. We were interested in finding out how in line with auction theory we were. I was looking through my old material from that study and I want to share a neat graph from that work that models how expected savings rise the more suppliers you include in an auction.
If you assume that all suppliers in a marketplace have a price evenly distributed between a low price and a high price then, on average, the savings you would get increase as shown in the graphic above. This helps emphasise that 4 bidders is a good number for a reverse English auction, as I have often said. But one thing to clarify: this is a model – you can do better than the model by ensuring that when you select potential suppliers that you are selecting suppliers who have a lower price rather than selecting suppliers at random from the marketplace.
Listened to Michael Krigsman’s podcast with Rod Boothby of Joyent about reliability/scaleabililty – a fairly hot topic in the blogosphere these days with the whole Twitter Up Twitter Down scenarios and recently with Amazon (about 00:35 in the podcast).
Around 01:20 Rod tells us that reliability is a known computer science problem with known solutions. And then at 01:27 he tells us that to develop something that scales is a simple architecture. But all he offers in terms of architecture is that different parts of your site should be correctly siloed , i.e. split off from each other. For example instead of having all your code under http://www.mysite.com you should put your uploads section under uploads.mysite.com and your messaging piece under messaging.mysite.com etc etc.
Michael asks a great question at 03:27: If it’s so easy why don’t more people do it properly?
Rod’s answer is that is all comes down to load balancing.
I’ve got a different answer. My answer is that the reason more people don’t do it is that in reality there’s a whole load more to availability, scalability and reliability than just load balancing across different subdomains.
Joyent is only talking about one tiny piece of the big availability/reliability/scaleability issue. And Rod is right that what he’s talking about is pretty easy to do. But it also has next to nothing to do with what usually happens to make complex sites struggle.
Usually the bottleneck is not the network or the bandwidth or the load balancing or the processing power of the web servers (these are all pretty easy to address). Usually the issue is the database itself. Partitioning the database into different silos (sharding) is VERY hard to do. It’s also very hard to predict early on what level of sharding you will need a few years down the line.
An example: when I first came to TradingPartners I inherited a system with 4 distinct databases. It had been designed this way to silo out different kinds of data. But it happend that 80 – 90% of the database calls were to one database. Bad design? No, simply that the original architect didn’t have a crystal ball to see where the application was headed. My scaleability issue has always been the database. Everything else is comparatively easy.
There is some great material on scaling at http://highscalability.com. And if you don’t believe me that there’s more to scaling than load balancing then check this great presentation from the LiveJournal/Danga people. There is a good Venn diagram on page 13 (and on page 14).
Two things caught my eye this week on the ongoing love/hate relationship between IT and Procurement.
IT doesn’t like Procurement
An article in Computer Weekly, 10 June 2008 print edition under the title: Procurement teams fail to serve IT. It reports on a talk given by Andy Kyte from Gartner. Some quotes from the piece:
Andy Kyte said that some businesses spend as much as 90% of their IT budgets on third-party suppliers but fail to get good value for money. Kyte said that IT procurement teams often act as if the only stakeholder they work for is the finance departments, and this is the reason why many deals do not add value and even lead to projects failing.
And, directly quoting Andy: “There is an obsession with cutting costs in IT procurement, but IT is about ensuring a better quality service to users.”
You’d expect Andy Kyte to know his stuff when it comes to procurement. After all, he’s featured here at AribaLive 2005.
Procurement doesn’t like IT
Which brings me to the this posting on the Ariba blog about Software As A Service vs IT. Here’s one quote: “it seems clear that IT’s tight grip on all things digital is gone and end users are winning the war.”
Which war? Justin goes on to explain:
What business user can survive without access to SaaS applications like WebEx or Salesforce? After a long battle over letting those and other apps through the network gates, the end users have won. IT simply can’t hold their end users back, strangling their productivity as more and more critical applications move online.
So can we ditch the stereotypes?
The stereotypes are there in full effect: From IT’s perspective, procurement is only about cutting costs. From Procurement’s perspective, IT is a gatekeeper which prevents users from doing business effectively. Sure there is some truth to both of those stereotypes. Yet at the same time there are CIOs who are looking at ways to break down information barriers within and between enterprises just as there are CPOs who are looking to generate value beyond unit price savings. From what I’ve seen in my professional life so far – which has touched both IT and Procurement – the similarities between the functions are greater than the differences.