May 24, 2011 1 Comment
There is a lot of talk in the industry around Collaboration and how collaboration, if done correctly, can increase sales, improve margins, enable companies to build innovative new products, business models and more.
There is also a lot of chatter about Unified Communications. The merging of eMail, Voice, Video and other technologies into a single system is once again promising improved productivity and lubrication of the collaborative processes…
A third driver in the industry at the moment is the notion of Enterprise 2.0 solutions – solutions that are delivered using “Web2.0″ principles. For the layman this means delivering the solution in a way that it runs completely in a browser, and indeed cross-browser and cross-platform. It means delivering them in a way that components can be easily reused. It means using web standards and not deploying thick clients or proprietary software. This is exactly what our Expertise Locator does… on top of an Linux server with PHP, Apache 2 and some perl thrown in for good measure.
This post, in short, is about delivering Enterprise 2.0 Communications Enabled Business Processes and the realities behind doing so.
I am not going to go into any of the reasons you may or may not want to collaborate or use UC in your organization. The case for and against collaboration is well laid out in Morten Hansen’s book titled “Collaboration” – available here…
The next step beyond understanding that you want to use Collaboration and Unified Communications is to pick the components that comprise your solution. Some you may own already, some may be pieces you are looking to buy and add on. Your friendly Vendor Salesperson will be more than happy to pitch the latest to you, and the industry folks out from Gartner and others will be more than happy to evaluate the solutions for you as well.
While we’re talking about things I am not going to do, I am also not going to talk about the rather looming trend of “Post-PC” devices and new forms of consumption, delivery and authoring. Once again, there are plenty of folks who will go on ad-nauseum about whether there is a trend, whether you should care and if you do, what to do about it. I will say up front that using true “Web2.0″ tools was the only way to develop a truly scalable, flexible app and widget framework.
Tying it all together:
What this blog post series will cover is the reality of tying all these systems together using Web2.0 or Enterprise 2.0 tools. I will do it by way of one of our simple examples here at Cisco…. It highlights some examples of what we see very often: An idea that sounds simple, but turns out to have a few kinks and snags – snags you can learn from and hopefully avoid, but more likely, anticipate.
This will also help to better inform, to some degree or another, any choices you may need to still make regarding Collaborative platforms, UC platforms, Application platforms and the looming specter of PostPc devices.
I see people buying systems, platforms and components in a vacuum… and I certainly don’t see them successfully doing much more than deploying a new IM client, or a new Collaborative Documents site. There are very few business apps being built and actually deployed.
Then buyer’s remorse sets in as they realize that the presence from the IM client can’t be displayed in their business app without mandating a browser choice… Which limits mobility.
Similar issues start cropping up in every workflow, and this happens again and again across apps…
An alternate issue is the belief that if you buy your entire solution from vendor A or Vendor B, and they will deliver the panacea you are looking for. It turns out that no single vendor can provide the complete collaboration+UC+application solution even assuming you could start fresh. They’re also certainly not all “Web2.0 friendly”. That wasn’t a surprise now was it? If you’re still thinking that you have it all sewn up, you may want to re-evaluate what you think “the solution” is… Likely your CEO has a different idea.
A tale of a business app:
As a way to delve into some of the complexities of these types of apps, we will take a look at a few UC-Enabled business applications that I have spent some time building as part of Cisco’s SOAR initiative.
Several whitepapers on Cisco’s site cover our SOAR initiative including:
“The new SOAR tools have made it much easier for employees to find resources, whether they exist on a webpage or in the mind of an expert. These tools have significantly increased Cisco’s sales. Product specialists report interacting with twice as many customers as they did previously, allowing them to devote much more of their time to customer engagement, instead of to tactical and research activities. In fact, SOAR tools allow Cisco to save the cost of one fulltime employee for every five specialists using SOAR. For a 100-person team of specialists that can now do the work of 120, that savings equates to more than US$5 million per year.
SOAR has also delivered significant improvements in employee efficiency. Product specialists and sales engineers report saving more than two hours each time they use the Rapid Response Team and Expertise Locator tools. Travel expenses for Cisco product specialists are down by as much as 60 percent in teams using SOAR tools, and specialists report saving 17 hours a week on average, and boosting their productivity by 22 percent.”
More details are available in the whitepaper including the journey taken from a business perspective and the requirements for collaboration and integrated UC functionality.
What is important for this blog series is how the tool developed: How and which functions were, or were not implemented… to produce a valuable business tool while remaining flexible enough to cover a variety of platforms, form factors etc.
The tool you see in the screen shots of the first link is the productized version of a UI and tool I had the pleasure of building and learning from. The original tool that I built also happens to be still used actively at Cisco for users to find subject matter experts, and has been running for over three years. It is a good example because it is simple, and is cleared to be shared externally from a Cisco perspective.
It integrates, in a single tool:
- Realtime Presence information from XMPP as well as SIP-SIMPLE sources. (This is used to sort result sets, not just place jellybeans on a page – a big deal)
Presence is delivered from Phone Systems, from IM clients; and by proxy WebEx meetings.
- Realtime free/busy information from Exchange
- Twitter feeds for Geolocation (Using OAuth)
- Directory, expertise and reporting information from Oracle
- Multiple Click-to- functionality (WebEx meeting, Voice Dial, Video Dial, Email, IM, Add buddy, View Directory, View Blog etc etc)
- User geolocation, and resulting Google maps.
In terms of functionality, the app:
- Implements a rating system so that those who look for help can rate the help they receive. (There is a lot to talk about here with HR. This is an opt-in choice)
- Records and reports on all interactions. (If you don’t know what collaboration is taking place, how do you know it was worth it?)
- Runs on IE, FireFox, Safari (Cisco does not dictate platform)
- Runs on Windows, Macs, iPhones, iPads (Cisco does not dictate platform)
- Allows for multi-selection of experts to initiate broadcast communications to a group of them.
So, in short, a lot of ‘stuff’ integrated into a single “Find me an expert” tool:
In each of these blog posts I will cover a single “Workload” and how it was integrated into the tool. I will discuss issues, insights and the resulting functionality wins and tradeoffs.
In the conclusion piece I will discuss some more sophisticated apps, such as Context+Presence aware queueing where task and project lists are rendered into a portal, displayed in order of “Most likely to be completable now, based on user, resource availability” (Think insurance adjusters and them needing multiple constituents, whether internal or external, and resources to be able to work and close a case – order caseload by “ability to get done”)