Monday, July 21, 2008
First Woman is Dutch, two in total, both from Delft
Fun to discover the Dutch women among the Anita Borg Scholars. UK and Russia have more of them, though.
Saturday, July 19, 2008
Mandatory Reading On Search Results Ranking
By far the most informative article I've ever read about how Google ranks its results:
Official Google Blog: Technologies behind Google ranking
Official Google Blog: Technologies behind Google ranking
Friday, April 25, 2008
Is your Service Better than Average?
If you think so, you're in good company: 75% of CEOs think the same. But you might be delusional as well, because 60% of actual customers are somewhat to extremely dissatisfied with their latest service experience.
That's what I read in this morning's Journal review of The Best Service Is No Service by Amazon alumnus Bill Price and Limebridge Sales and Service Consulting Director David Jaffe.
Once at work, there was no way that WSJ's search bar would find the article (boo!), but fortunately I googled upon Guy Kawasaki's blog-interview with Bill Price . That article has a lot of gems too, like how to find companies with bad service:
So how do our Service Networks help address Bill Price's Seven Principles, and how do implicit web techniques factor into that?
1. Eliminate dumb or avoidable contacts to free up capacity and slash costs
A study at Oracle showed that 99.9% of all service requests were satisfied with known information. This is why service networks focus on making existing information easily accessible, thus eliminating a huge amount of dumb or avoidable contacts. Implicit web techniques help organize the information by extracting the domain language and creating a Service Encyclopedia. Implicit web techniques also help match service requesters to the information they need -- think Amazon's "people who looked at this book ended up buying this other book".
2. Build self-service that works to free up even more capacity and cut costs even more
One of the most powerful forms of self-service is your customers helping each other. This type of participation on our Service Networks goes far beyond classic forum discussion: you can initiate a discussion on any page ("does this procedure apply to the revision that I have?"), chat with people related to the topic or issue, and share or tag relevant information such as test plans or best practices. Implicit web techniques are used to emphasize the most relevant people and information.
3. Find ways to be proactive rather than reactive because it is often cheaper than waiting
Service networks index and analyze everything that's going on so you can see issues developing much earlier -- including mood analysis that flags developing irritation. It's also easier to target news to the people that need to know.
4. Engage the real "owners" of customer problems to work with the customer service team to fix the problems
Traditionally vendors of high-tech products have flouted this principle by limiting the number of people they would interact with at each customer, because they feared losing control over the flow of information. On a service network this is no longer necessary because all people, information and transactions are linked and transparent. At any given point in time, the most appropriate people from both vendor and customer can work on the issue at hand.
5. Make it really easy to contact your business
Service networks provide myriad ways of contact (chat, email, forum dialog, phone, desktop sharing) and what's more, they're linked so you don't have to reconstruct context at every contact (please tell me again your account number).
6. Use the contacts you get to listen closely to the customer, and act upon WOCAS (What Our Customers Are Saying)
This also gets easier because the service network extends into the entire enterprise. No transferring problem descriptions from the CRM system to the developer Bug system and Requirements Management system. We just index all three systems and derive the links. On top of the indices we create dashboards to track (categories of) issues and drilling down into the specifics of any issue is just a click away.
7. Fix reporting metrics, processes, and the staffing side to deliver great experiences for customer contacts
When we were just getting started, we made an extensive study of Amy Jo Kim's Community Building on the Web : Secret Strategies for Successful Online Communities . Her #1 advice is that an on-line community should have a (published) purpose. Whenever we start a new Service Network for one of our customers, we make sure we define its purpose, which should be more specific than "offer great customer service". Instead we set targets that include one or more of Bill's CPX metrics, e.g. "Reduce the average number of contacts to resolve an issue by 20% in 2008".
Service Networks make it easy to define, explain and publish their purpose, as well as publish metrics showing how they're doing.
That's what I read in this morning's Journal review of The Best Service Is No Service by Amazon alumnus Bill Price and Limebridge Sales and Service Consulting Director David Jaffe.
Once at work, there was no way that WSJ's search bar would find the article (boo!), but fortunately I googled upon Guy Kawasaki's blog-interview with Bill Price . That article has a lot of gems too, like how to find companies with bad service:
"All you need to do is look for companies that hide their phone number on web sites"and
"We have yet to find a company that couldn't improve service and cut costs at the same time"The latter could have been a quote from our CEO Mike Rocha whose major claim to fame is having done exactly that at Oracle Corporation, and who founded our company to do it again (but better) for the rest of the world.
So how do our Service Networks help address Bill Price's Seven Principles, and how do implicit web techniques factor into that?
1. Eliminate dumb or avoidable contacts to free up capacity and slash costs
A study at Oracle showed that 99.9% of all service requests were satisfied with known information. This is why service networks focus on making existing information easily accessible, thus eliminating a huge amount of dumb or avoidable contacts. Implicit web techniques help organize the information by extracting the domain language and creating a Service Encyclopedia. Implicit web techniques also help match service requesters to the information they need -- think Amazon's "people who looked at this book ended up buying this other book".
2. Build self-service that works to free up even more capacity and cut costs even more
One of the most powerful forms of self-service is your customers helping each other. This type of participation on our Service Networks goes far beyond classic forum discussion: you can initiate a discussion on any page ("does this procedure apply to the revision that I have?"), chat with people related to the topic or issue, and share or tag relevant information such as test plans or best practices. Implicit web techniques are used to emphasize the most relevant people and information.
3. Find ways to be proactive rather than reactive because it is often cheaper than waiting
Service networks index and analyze everything that's going on so you can see issues developing much earlier -- including mood analysis that flags developing irritation. It's also easier to target news to the people that need to know.
4. Engage the real "owners" of customer problems to work with the customer service team to fix the problems
Traditionally vendors of high-tech products have flouted this principle by limiting the number of people they would interact with at each customer, because they feared losing control over the flow of information. On a service network this is no longer necessary because all people, information and transactions are linked and transparent. At any given point in time, the most appropriate people from both vendor and customer can work on the issue at hand.
5. Make it really easy to contact your business
Service networks provide myriad ways of contact (chat, email, forum dialog, phone, desktop sharing) and what's more, they're linked so you don't have to reconstruct context at every contact (please tell me again your account number).
6. Use the contacts you get to listen closely to the customer, and act upon WOCAS (What Our Customers Are Saying)
This also gets easier because the service network extends into the entire enterprise. No transferring problem descriptions from the CRM system to the developer Bug system and Requirements Management system. We just index all three systems and derive the links. On top of the indices we create dashboards to track (categories of) issues and drilling down into the specifics of any issue is just a click away.
7. Fix reporting metrics, processes, and the staffing side to deliver great experiences for customer contacts
When we were just getting started, we made an extensive study of Amy Jo Kim's Community Building on the Web : Secret Strategies for Successful Online Communities . Her #1 advice is that an on-line community should have a (published) purpose. Whenever we start a new Service Network for one of our customers, we make sure we define its purpose, which should be more specific than "offer great customer service". Instead we set targets that include one or more of Bill's CPX metrics, e.g. "Reduce the average number of contacts to resolve an issue by 20% in 2008".
Service Networks make it easy to define, explain and publish their purpose, as well as publish metrics showing how they're doing.
Thursday, March 27, 2008
Twine, Applications and Green Fields
Looking at Robert Scoble's interview with Twine's Nova Spivack reminded me of Freebase, Knol and countless others before. Basically the interview goes like this:
1. Sir Tim Berners-Lee* has talked about the importance of the data web, or more recently about the Giant Global Graph (GGG)*.
2. Twine has built technology that can create, maintain and query a data web.
3. Let's sit at our editor, create a little data web, and run a query
4. Look how beautiful, imagine all the wonderful things you could do with this!
* Substitute appropriate visionary here, like Danny Hillis or Won Kim
** Substitute appropriate information infrastructure technology like "semantic database", "object-oriented database", etc.
Now I did enjoy the interview and the editor does look nifty but I was still a bit disappointed.
First because the presentation is very technology centric, cleverly leaving the applications to the imagination. But what's a dataweb (or any information infrastructure) without applications? No, the editor from step 2 doesn't count as an application. Even a query interface or browser barely deserves that qualification.
Compare that to a database like Oracle. The relational database concept developed by Jim Grey et al was a major breakthrough, as was the query language SQL. But there really isn't much use to a relational database until you run business applications on top of it -- think of Payroll or Shopping Cart. Oracle didn't win the database war from IBM, Informix, Tandem, Microsoft and countless others because their database was technologically most advanced, but because they focused on the applications -- lately in the extreme by selling the database as well as its applications, either developed in-house or obtained through myriad acquisitions. Here's a list, and that's only the "strategic" acquisitions!
So I perked up when Robert asked "what are the applications you have in mind", but I slumped back when I heard Nova answer "we think this is something that would be used by work groups".
The second disappointment was what I call the "Green Field Approach". The demo starts with Nova creating a Twine, cutting and pasting some text, and then creating relations with other twines and some existing web pages. A bit further in, Nova shows how you can import information from other sources, but that seems an afterthought: "we're looking at what other sources might be interesting".
But given the terabytes of information that are already out there it seems the last thing we need is human authors creating new pages -- shouldn't the main goal be to navigate, organize, link and clean up existing information? Shouldn't creating the dataweb be as easy as tagging -- which very successfully avoids the creation of original content?
The best of luck to information technology companies -- we definitely think of ourselves as one.
But remember:
1. Sir Tim Berners-Lee* has talked about the importance of the data web, or more recently about the Giant Global Graph (GGG)*.
2. Twine has built technology that can create, maintain and query a data web.
3. Let's sit at our editor, create a little data web, and run a query
4. Look how beautiful, imagine all the wonderful things you could do with this!
* Substitute appropriate visionary here, like Danny Hillis or Won Kim
** Substitute appropriate information infrastructure technology like "semantic database", "object-oriented database", etc.
Now I did enjoy the interview and the editor does look nifty but I was still a bit disappointed.
First because the presentation is very technology centric, cleverly leaving the applications to the imagination. But what's a dataweb (or any information infrastructure) without applications? No, the editor from step 2 doesn't count as an application. Even a query interface or browser barely deserves that qualification.
Compare that to a database like Oracle. The relational database concept developed by Jim Grey et al was a major breakthrough, as was the query language SQL. But there really isn't much use to a relational database until you run business applications on top of it -- think of Payroll or Shopping Cart. Oracle didn't win the database war from IBM, Informix, Tandem, Microsoft and countless others because their database was technologically most advanced, but because they focused on the applications -- lately in the extreme by selling the database as well as its applications, either developed in-house or obtained through myriad acquisitions. Here's a list, and that's only the "strategic" acquisitions!
So I perked up when Robert asked "what are the applications you have in mind", but I slumped back when I heard Nova answer "we think this is something that would be used by work groups".
The second disappointment was what I call the "Green Field Approach". The demo starts with Nova creating a Twine, cutting and pasting some text, and then creating relations with other twines and some existing web pages. A bit further in, Nova shows how you can import information from other sources, but that seems an afterthought: "we're looking at what other sources might be interesting".
But given the terabytes of information that are already out there it seems the last thing we need is human authors creating new pages -- shouldn't the main goal be to navigate, organize, link and clean up existing information? Shouldn't creating the dataweb be as easy as tagging -- which very successfully avoids the creation of original content?
The best of luck to information technology companies -- we definitely think of ourselves as one.
But remember:
No Apps, No Glory!and
There is Plenty Information Already!
Sunday, March 23, 2008
Wikinomics and Maslow's hierarchy of needs
Reading Wikinomics I wondered what it takes for wikis to work in the enterprise. Jimmy Whales, the head Honcho of Wikipedia, has said that 0.7% of users did 50% of the edits on Wikipedia. If those same numbers held for the enterprise, a 1,000 person company's wiki would hinge on the contributions of 7 people. There has been debate about the Wikipedia numbers, but beyond that debate the numbers don't translate to the enterprise because the incentives are different.
What are the incentives to produce content on Wikipedia? There is the altruistic motive of providing free (as in beer) truth to the world, there is the satisfaction of finding and correcting flaws and, perhaps most important, the value of asserting yourself as a topic expert.
Referring to Maslow's hierarchy of needs, none of these incentives translate into level one (physiological) and two (safety) needs, perhaps "belonging to the Wikipedia community" might qualify at level three.
Contrast that with creating or editing a useful page on your company's wiki. Saving colleagues time not only improves the bottom line but might get you noticed by your manager or perhaps even your manager's manager, both of which translate into food and safety (of employment).
While we couldn't extrapolate our numbers because service networks go far beyond wikis -- especially by automatically providing much-needed structure -- we have been seeing the power of those incentives during implementations of Service Networks for Upgrades. Traditionally, non-IT employees shy away from tasks in planning or testing an Oracle Upgrade, but when they see how their contributions will be visible on the network, they often jump on board. With the help of their published experience, upgrades are completed in half the traditional time and at one quarter the traditional cost.
As a lot of momentum is going into Enterprise 2.0, I hope to see more of this type of quantification. While Wikipedia and Facebook may run on Maslow's belonging, esteem and self-actualization, mainstream enterprises will need to understand the material impact on their business for Enterprise 2.0 to really take off.
What are the incentives to produce content on Wikipedia? There is the altruistic motive of providing free (as in beer) truth to the world, there is the satisfaction of finding and correcting flaws and, perhaps most important, the value of asserting yourself as a topic expert.
Referring to Maslow's hierarchy of needs, none of these incentives translate into level one (physiological) and two (safety) needs, perhaps "belonging to the Wikipedia community" might qualify at level three.
Contrast that with creating or editing a useful page on your company's wiki. Saving colleagues time not only improves the bottom line but might get you noticed by your manager or perhaps even your manager's manager, both of which translate into food and safety (of employment).
While we couldn't extrapolate our numbers because service networks go far beyond wikis -- especially by automatically providing much-needed structure -- we have been seeing the power of those incentives during implementations of Service Networks for Upgrades. Traditionally, non-IT employees shy away from tasks in planning or testing an Oracle Upgrade, but when they see how their contributions will be visible on the network, they often jump on board. With the help of their published experience, upgrades are completed in half the traditional time and at one quarter the traditional cost.
As a lot of momentum is going into Enterprise 2.0, I hope to see more of this type of quantification. While Wikipedia and Facebook may run on Maslow's belonging, esteem and self-actualization, mainstream enterprises will need to understand the material impact on their business for Enterprise 2.0 to really take off.
Wednesday, January 16, 2008
Knols, Wikipedia and truth in Openwater Service Networks
Last month, Google unveiled knols. In Udi Manber's words,
The key idea behind the Knol project is to highlight authors.
Unlike Wikipedia, which contains a single definition for each topic, authors write competing knols about the same topic.
Udi argues that competition is a good thing. Google will not edit the knols, but use its considerable Search Quality expertise to let the best version float to the top.
Considering Wikipedia and Knol raises interesting philosophical questions about truth. Take Hugo Chávez . Many view him as a socialist liberator, many others view him as an authoritarian demagogue.
Wikipedia editors deal with these versions of the truth in a variety of ways, labeling actions or statements as "controversial", requiring references to facts from reputable sources, flagging text as "opinion" and even introducing a separate topic Criticism of Hugo Chávez . However admirable these efforts, some bias undoubtedly remains. For example, these graphs make him look like a hero to a visual person like me. The text next to it has enough nuance that I couldn't tell. And that's where Wikipedia (or any encyclopedia, for that matter) usually leaves me -- my head full of facts from more or less reputable sources, various conflicting interpretations of these facts but no point of view.
Enter Knol. Knol isn't live yet, but I imagine we'd get at least two knols: Hugo the Good and Hugo the Bad. It will be interesting to see which Hugo will float to the top -- it will be a reflection of the community that views and rates knols.
The word "community" provides a good segueway into what we do at Openwater. Rather than demanding one version of the truth, or letting several truths compete, we build service networks for communities (specifically the installed base of a high-tech product), each of which creates its own Community Encyclopedia.
As in Wikipedia, anyone in the service network can edit a topic and each topic has experts assigned who monitor the quality. But like Knol, the editors don't have to balance every sentence that appears to carry an opinion or bias. And perhaps the biggest difference with both Knol and Wikipedia: there is no need to consider all possible meanings of each word -- just the current meaning within the installed base community is fine.
As a result, topics can be more specific and concise than those in either Knol or Wikipedia, and at the same time they can index more specific (proprietary) information and people in the installed base community.
There is one other major difference I'd like to mention in this blog -- this is what makes us an "implicit web" company. Unlike Wikipedia and Knol, topic pages don't start as an empty page and a blinking cursor.
In an Openwater Service Network, we start by indexing all the structured and unstructured information that's already available to the installed base, such as technical documentation, forums, bug tracking systems, LDAP directories, mailing lists, project plans, etc.
From the index, we then extract candidate topics by applying Natural Language Processing techniques to the unstructured text and by applying queries to the structured information. These candidate topics come with links to relevant documents, people, terms and other information. Users select suitable topics and refine them into the Community Encyclopedia.
The resulting pages look a lot like those in Wikipedia and Knol, but they're a lot more relevant to the community and a lot less effort to produce.
Because of the way it's built, we can also use the encyclopedia to program the network, but that's another story.
The key idea behind the Knol project is to highlight authors.
Unlike Wikipedia, which contains a single definition for each topic, authors write competing knols about the same topic.
Udi argues that competition is a good thing. Google will not edit the knols, but use its considerable Search Quality expertise to let the best version float to the top.
Considering Wikipedia and Knol raises interesting philosophical questions about truth. Take Hugo Chávez . Many view him as a socialist liberator, many others view him as an authoritarian demagogue.
Wikipedia editors deal with these versions of the truth in a variety of ways, labeling actions or statements as "controversial", requiring references to facts from reputable sources, flagging text as "opinion" and even introducing a separate topic Criticism of Hugo Chávez . However admirable these efforts, some bias undoubtedly remains. For example, these graphs make him look like a hero to a visual person like me. The text next to it has enough nuance that I couldn't tell. And that's where Wikipedia (or any encyclopedia, for that matter) usually leaves me -- my head full of facts from more or less reputable sources, various conflicting interpretations of these facts but no point of view.
Enter Knol. Knol isn't live yet, but I imagine we'd get at least two knols: Hugo the Good and Hugo the Bad. It will be interesting to see which Hugo will float to the top -- it will be a reflection of the community that views and rates knols.
The word "community" provides a good segueway into what we do at Openwater. Rather than demanding one version of the truth, or letting several truths compete, we build service networks for communities (specifically the installed base of a high-tech product), each of which creates its own Community Encyclopedia.
As in Wikipedia, anyone in the service network can edit a topic and each topic has experts assigned who monitor the quality. But like Knol, the editors don't have to balance every sentence that appears to carry an opinion or bias. And perhaps the biggest difference with both Knol and Wikipedia: there is no need to consider all possible meanings of each word -- just the current meaning within the installed base community is fine.
As a result, topics can be more specific and concise than those in either Knol or Wikipedia, and at the same time they can index more specific (proprietary) information and people in the installed base community.
There is one other major difference I'd like to mention in this blog -- this is what makes us an "implicit web" company. Unlike Wikipedia and Knol, topic pages don't start as an empty page and a blinking cursor.
In an Openwater Service Network, we start by indexing all the structured and unstructured information that's already available to the installed base, such as technical documentation, forums, bug tracking systems, LDAP directories, mailing lists, project plans, etc.
From the index, we then extract candidate topics by applying Natural Language Processing techniques to the unstructured text and by applying queries to the structured information. These candidate topics come with links to relevant documents, people, terms and other information. Users select suitable topics and refine them into the Community Encyclopedia.
The resulting pages look a lot like those in Wikipedia and Knol, but they're a lot more relevant to the community and a lot less effort to produce.
Because of the way it's built, we can also use the encyclopedia to program the network, but that's another story.
Subscribe to:
Posts (Atom)
