Now that we’ve got an e2.0 platform up and running we’re looking at our next big phase in turning everything social:  integration with (or replacement of) other enterprise systems.  One of the first that comes to mind is our Skills DB.  The Skills DB does what it sounds like – it’s a database of skills.  However, now that each employee has a social profile on this new e2.0 platform, a portion of which contains skills information, what’s the point of having a separate system that has essentially become redundant?  Additionally, retiring an enterprise system like the Skills DB would certainly help the e2.0 business case.

In the 1.0 world, an employee was required to access the Skills DB once a year and update his/her skills with ‘level of experience’ and ‘last time used’ information; afterwards the employee’s supervisor would log into the system and validate the information.  In the 2.0 world, that process becomes unnecessary.  It will be important for employees to have a current listing of their skills for search and ‘recommendation’ reasons.  But an employee’s skills or expertise will be determined in other ways.  If your e2.0 system is designed to be put in the knowledge worker’s workflow, their profile will be dynamically generated by the work they do:  the documents they author, the ideas they generate, the discussions they participate in, the artifacts they tag, the questions they answer, the reviews their peers generate through feed-back loops.

Now, when a hiring manager is looking for a software engineer with .NET experience, instead of going to an isolated Skills DB (where the info might be a year old), all they have to do is a quick search in the e2.0 tool.  Immediately they will be given much richer, up-to-date, information on all the employees with that skill set.  Plus, the hiring manager will be able to validate the claimed skill by looking through the activity of the employee, the projects they’re currently working on, the feedback from peers, etc…

Some takeaways:

• We can retire an enterprise system – good, bottom line-savings there
• Employees no longer have to compartmentalize logging their skills as a separate part of their day, it’s now in the workflow – good, productivity gain, current skills info maintained
• We’ve completely revamped the way we manage our skills and look for talent to fill internal job req’s.   – process improvement, if we can fill reqs faster, we can get to market faster
• ‘Work’ is now out in the open to be judged  - wow
• Peers can provide feedback in an open, public forum – geez (are we ready for this?), skill validation can now be vetted as opposed to the opinion of one person
• Information (Skills DB) previously accessible/searchable only by hiring managers is now out there in broad daylight for anyone to see/search/use – empowering, organizationally flattening, potential for emergent outcomes.

Ever think you know someone really well and then you meet one of their siblings and they’re completely different?  You never could have imagined it.  Same parents, same church, same school, same neighborhood.  What gives?  One goes out all the time, the other stays in.  One got straight A’s, the other never finished high school.  One likes their beef grass-fed, the other is vegan.  I think you get the idea.

Well, IT projects can be a lot like that.  You can have two projects, same goal and they can be worlds apart.  Same company, same vision, same CEO, same culture, same training.  What gives?  Well, I’ve had the opportunity to work in such an environment (project = e2.0 deployment) and I can tell you what gives.  It’s the requirements.  Well, not so much the requirements but from whom they come.   Talk to IT.  Talk to BD.  Then talk to HR, Marketing, Comms.  Then go and talk to your ‘product’ folks.  Worlds apart.  Even though everyone at the company is committed to the same mission, they’ve each got their own role and their own care-abouts.  The ‘thing’ they want designed is obviously going to be biased to what makes their world tick.

So, to whom do you listen?  It’s a tough decision in the ’social world’.  My advice is actually the same I offered in this post I wrote in June (I was at the e2.0 Conference in Boston).  The difference is that now (more than 3 monhts later) I’ve got the experience to back it up.  Turns out I was right.  Doesn’t happen often.  But when it does I’m going to blog about it.  Here’s an excerpt:

My advice to you is do your homework.  Know the vendor space, know your architecture, know your security model, know your requirements.  Most importantly: know your business and how this new tool set will help you solve your BUSINESS problems.  Do all of this before even approaching a vendor.  Get a sponsor from your BUSINESS.  HR is not OK.  Comms, eh, you’re getting warmer.  IT…COLD.  Get at the heart of what your company does and find out who does it.  Once you find them, they will tell you everything you need to know.   If you can make them happy and solve their problems you greatly increase your odds of success.

Looking back on that advice, it’s a little rough around the edges, but it absolutely rings true.  Jeremiah Owyang has a new post here where he urges companies to bring ’social’ beyond just the marketing department.  I agree, but if you’re talking internally focused efforts (and I understand that wasn’t his intent, so this is not a criticism) his advice doesn’t go far enough.  You need to start with the ‘core of your business’ folks.  They will cover many requirements of the other functions, but it won’t work the other way around.  Once you get the right requirements from the right people you’ll have created an excellent foundation from which you can become holistic.

Having lunch at Cowboy Chow in Dallas