Archive for ‘strategy’

November 29, 2010

Think Communities, Not Portals!


If you are planning your SharePoint 2010 upgrade and looking at redesigning the hundreds of intranet sites — stop right there!   Don’t redesign, rethink your corporate intranet.

I spend a fair amount of time with clients discussing the redesign of their sites and in most cases I continue to hear the word “portal” mentioned.   When I think of portals, I jump into my time machine and go back a decade or so.  Portals are plain and generally have static web content with outdated information that is seldom accessed by employees.   Look at your intranet today and it’s likely you’ll see a SharePoint site with all kinds of links that’s not very interactive or relevant to individuals.  Maybe you have top-down executive blog that is posted to once a quarter or once a month if you’re lucky.   If the corporate intranet page wasn’t set as the employee home page in the browser, I wonder how many people would actually visit it?  .  Sound like your intranet?  So what’s the point of upgrading to SharePoint 2010 if you’re just going to migrate those plain boring sites you have today?

It’s time to break away from the traditional thinking of intranet “portals” and design a collaborative infrastructure around a complete “community model”.  What do I mean exactly?   If you compare a community to the traditional portal, you may think it’s just a matter of semantics.   However, the concept of a portal is a push relationship as someone is pushing content to you.  Communities are social, interactive, dynamic, and provide a context for individuals to subscribe, collaborate and contribute to.   Communities source information from the bottom up as well as the top down.  Communities have a pull relationship — meaning the community pulls on users to contribute and users pull on the community to consume.  The fact is that every piece of content and every person in your organization is part of some community whether you realize it or not.  The largest and most open community is everyone in your organization and there are likely hundreds or thousands of sub-communities.   Communities also provide a degree of openness in your organization.  So if the information you wish to share has more defined security requirements, that’s when you manage it in a secure team site as opposed to a community.

Now I know what you’re thinking — “we have to have a hierarchical intranet portal”.   Really do you?  Do you need it to be hierarchical?   Sure you might need a directory for people or sites for easier navigation.  You also need enhanced search capabilities as most people would rather search than browse.   Just think about it — is the public internet hierarchical?   Does Google or Facebook or LinkedIn have any hierarchy?   In comparison, you could look at Yahoo as a traditional portal — static, boring, and a site people rarely view anymore.  And that’s why Yahoo has lost market share and relevance today.

Let’s face it — for many of us Facebook is our “portal” on the public internet  and something we visit 1 or more times a day because it’s social and relevant to us personally.  LinkedIn may be your “portal” into your professional life and network.   Do you really need a traditional hierarchy of intranet sites and portals?   Or is it more important to capture, share, and collaborate on information within the context of a community?

 

Advertisements
October 7, 2010

ROI of SharePoint – An Example


In a recent post, I talked about ROI of SharePoint and how there are many hidden “soft costs” within business activities — which are probably not measured in most organizations today.    A good use case for measuring ROI of SharePoint is a set of business activities around managing IT contractors.

Many IT organizations both large and small utilize contractors and consultants. In many global enterprises, you might have several thousand contractors in and out of your organization over a calendar year. The process of hiring contractors and consultants is often times a painful one. It takes weeks if not months, lots of back and forth emails, paper forms and approvals, resumes, interviews, rate discussions, on-boarding, and more… Project timelines are impacted and the demand for IT project requests starts to backlog because it takes too long to get the right IT resource into your organization and onboard. In the absence of an expensive “vendor management” system, the end to end process can seem like a chaotic dance of emails, paper, and documents.

Just as there is a cost in hiring a full time employee, there’s a cost of on-boarding a contractor. Additionally, if you’re not tracking vendors, candidates, or rates, how do you know you know you’re getting the best candidate for the lowest rate? Do you know the average bill rate of your contractors or for a particular vendor? Are you measuring the cycle time for an IT manager to initiate a resource request through the on-boarding? Do you know the dollar impact resource delays have on project schedules and costs? Do you know what metrics you should be measuring at all? These types of questions beg for a solution built on SharePoint to help you manage the information and documentation, communicate status, and report on key performance indicators (KPIs) you indentify to be important to your organization.

Before you even begin to start building your solution on SharePoint, you’ll want to begin by mapping the end to end business activities, approvals, and flow of information and documents. The next step involves developing an “information architecture” with the appropriate content types and metadata you are looking to capture. Part of this exercise involves understanding what KPIs you are looking to measure as that will drive some of your taxonomy. Where possible, you also want to attempt to estimate time and dollar costs of the existing process so you can compare those estimates after you implement the solution built on SharePoint. There are obvious hard costs like the hourly rate of a resource. Soft costs might be the time required for approvals, time waiting for hiring decisions, or interview feedback. There are also less obvious soft costs such as cost of turnover, lost productivity, low morale, lost sales, or missed opportunities.

So let’s look at an example to see how much lost productivity we might find in this example of IT contracting staffing requests:

  1. Let’s assume you receive about 2000 IT staffing requests a year.
  2. The average processing time for fulfilling IT staffing requests is on average 6 weeks (or 240 working hours).
  3. The lost calendar hours waiting for staffing requests to process would equate to 480,000 lost hours per year waiting (2000 requests * 240 hours waiting per request).
  4. Those 480,000 total calendar hours divided by 24 = 16,667 days total waiting.
  5. Multiply 16,667 days waiting times 8 hours in a day = 133,336 Lost Productive Work Hours Waiting for IT Staffing Requests in this example.
  6. The average hourly rate of your employees (those submitting and fulfilling the requests) is estimated at about $55/hour.
  7. $55 * 133,336 lost productive hours = $7,333,480 as the Total Cost of Loss in Productivity

Once you understand the end of end process and estimate the current loss in productivity involved in the current set of business activities, you can then begin to set a target such as reducing the request fulfillment time by 50%.  Then you can begin to leverage the capabilities of SharePoint.  The assumption is you probably already have it inside your organization and all you need is your own Site Collection.  The costs are minimal and you can now provide IT managers a place to request resources via a centralized SharePoint web form and self-track the progress of their requests and candidates throughout the interview process.   You can empower the individuals who work with outside staffing agencies to manage the candidates and resumes, present them in SharePoint to the hiring manager and include the in-flow of information and documents all within SharePoint lists and libraries with appropriate metadata.   Managers can enter feedback and executives can approve billing rates.  Lastly, you can begin to report to executives and measure cycle times, average billing rates, and more — all from the data and information captured in the solution built on SharePoint.

Just imagine this SharePoint solution allows you to reduce the time it takes to fulfill IT Staffing requests by 20% or 50%?   In our example, that’s a cost savings of millions that are measurable and easily communicated to executives and business leaders to justify the cost of SharePoint and showcase the value and ROI of the technology platform.

Tags: ,
September 30, 2010

Why is measuring a hard ROI for SharePoint just so hard?


Traditionally when it comes to implementing technology, the financial bean counters and decision makers have looked for hard dollars for the ROI of a technology investment. However, when it comes to SharePoint, it seems we have thrown a hard ROI out the window. In a manufacturing or factory environment, it’s generally easy to measure hard dollar costs of raw materials or labor costs or costs per hour. Centuries of economic theory and practice led to the pioneering of the “scientific method” in the early part of the 20th century by Frederick Taylor and Henry Ford among others. Implement “robot X” into the assembly line and produce more widgets and save on labor costs. We have also had a few decades of TQM (total quality management) which has evolved into many buzzwords all seeking efficiencies in productivity of manufacturing and supply chains. In Business School, I remember learning all kinds of management theory on these subjects and “generally accepted accounting principles” to calculate hard dollar costs and manage budgets to actual as well as profitability of goods sold. So what happened to measuring ROI of SharePoint and why isn’t there enough written on it?

I have read tons of articles on web 2.0, collaboration, and SharePoint. They evangelize about grand topics like innovation and creating opportunities through communities and connecting people through social sites. Some talk about the vision of enterprise content management being realized at an enterprise level. And some articles even try to address ROI and talk about the “downstream effects” of capturing ideas and information in blogs or wikis. Then we hear from executives and decision makers that evangelizing the technology sounds great, but all the benefits are “soft” and too hard to measure. Okay, so why not measure “soft costs”?

The reality is that all businesses have soft costs such as turnover, lost productivity, low morale, lost sales and missed opportunities. And any combination of those might drive soft cost dollars in your organization which can have big impact on your bottom line — sometimes just as much as the hard costs and other times even more. Many organizations simply don’t measure these types of costs because they don’t understand it or simply don’t have the capability to measure them. Or perhaps people are just focused on meeting deadlines without questioning the value or impact to the customer. Meanwhile, project management within many organizations seems like chaos, deadlines get missed, decisions are delayed, tiger teams get formed, and the insanity of our day to day work life continues. Projects that should take only a few weeks or a few months, takes 12 or 18 months to complete and quality suffers as does employee morale. You continue to wonder why things in your organization aren’t as easy as what we see on Google or Facebook. Then we recharge on the weekend, read the Dilbert cartoon in the Sunday paper, laugh and think of our own work environments, and do it all over again next week. All the while we continue to email each other on our smart phones and at best upload documents to a site on SharePoint. And if you’re paying attention, there are no doubt hidden costs in many of the things just mentioned.

In today’s economic climate, it’s time we take a hard look at dollars and sense and focus on driving analytics from a collaboration & information management platform like SharePoint. In my next series of blog entries, I’m going to focus on making measuring a hard ROI less hard and relate it specifically to real solutions implemented on SharePoint.

Tags: ,
September 23, 2010

Now that I have SharePoint, what do I do with it?


It continues to amaze me how many organizations have SharePoint or go out and purchase it but still aren’t sure what to do with it.  While you could easily show them the SharePoint wheel or talk about features, functions or capabilities…it isn’t enough.   Simply saying SharePoint is a collaboration tool is not enough as “collaboration” itself is such an abstract term.  While you could simplify SharePoint and say that everything inside the application is really a “list” with rows and columns used to track things, that isn’t quite enough.  So it’s usually best to begin the conversation by relating SharePoint to people’s day to day work activities.  The goal is to show people there’s a better way of working than they do today.

Executives and business managers seem to understand ERP & CRM systems, data, reports, and transactional processes.  However, most people don’t realize there’s a whole set of collaborative “activities” that need to happen to actually generate the required data to enter into those transactional systems.  The below diagram outlines this in more detail.   It shows the business activities that occur before, during, or after entering raw data into number crunching transactional ERP/CRM systems.  It’s the top half of the diagram — the “Unstructured Activities” — that SharePoint as a technology platform focuses on.  SharePoint’s capabilities were designed to surface information and address unstructured content, knowledge, activities and the social interactions that take place in business.

Ideally, you’ll want to pick a business process executives and workers are familiar with or processes that touch a painful nerve in those individuals.  Maybe it’s the sales process, or onboarding of new employees, or some other internal operation or customer facing activity.   Have them identify all the Word tables and Excel documents in which they track information on their desktops.  Map out the value chain — the people, emails, documents, activities and workflows, and the points where raw data is used and decisions are made.   Once you do that, you can easily begin to propose and prototype a solution that can be implemented with the capabilities that SharePoint provides.   You can begin to educate people on what’s possible, show them how SharePoint can alleviate some common day to day headaches, and get them excited about the possibilities and changes to come.

September 17, 2010

Don’t Forget the Change in your SharePoint Investment


We have seen SharePoint sites pop up and virally explode.  We have seen SharePoint used in many cases as a basic document repository.  In some organizations, we’ve also seen SharePoint used for collaboration, project management, or even process improvement.  No matter how SharePoint is used in your organization, you’ve probably taken a standard approach to implement the technology with the typical project elements:

  • Identify business need or opportunity.
  • Define the Project.
  • Design of Business solution.
  • Develop new processes and solution.
  • Test, implement, and train.

Or maybe you’ve gone one step further properly planning and outlining your roadmap to build out a centralized SharePoint infrastructure with a clear migration strategy for your legacy intranet or fileshares or collaboration spaces.  However, the traditional approach we normally take to deploy technology has resulted in many non-believers and those who continue to under-leverage the capabilities of SharePoint and rely on the old ways of doing things.

Yes, it’s important to create a solid technical infrastructure.  Like building a foundation to a house, you need a stable platform that can scale and perform for users no matter where they are in the world. And yes, you also need good governance of the SharePoint platform to manage and support users and the growth in demand.  While a secure technical infrastructure and good governance are 2 keys to a successful deployment of SharePoint, there is still one thing missing.   A critical ingredient which is not discussed or blogged about much is the change management component that SharePoint requires to break old habits and fundamentally transform how knowledge workers approach their day to day.   When I talk about change management, I am referring to people but not necessarily referring to the social capabilities of the software.  I’m referring to how SharePoint as a technology can reshape the “industrial psychology” of how knowledge workers connect, collaborate, communicate, and actually get work done in today’s service-driven economy.   While there are a number of methodologies and approaches to managing change, there seem to be a few common themes among the different schools of thought:

  1. Assess your organizations readiness for change.  Is it incremental or transformational? Are people aware they need to change?  Is there a sense of urgency?  Do they have the desire?  Where is there resistance?
  2. Knowledge about the change and vision.  People need to learn new abilities and ways of approaching the same work with the new capabilities that the technology offers.
  3. Empowerment and reinforcement.  People need to take ownership and the behaviors need to be reinforced.  There needs to be some short term wins and long term vision and approach to make the change become permanent.

SharePoint needs to be seen as a productivity tool and not just a place to store documents.  For this to happen, building the best solution on SharePoint is not enough.  Training and adoption can’t be an afterthought that happen towards the end of the implementation.  Change management needs to be part of the plan and addressed up front.   At the end of day, SharePoint is a platform that is not just about information management or some broad concept like collaboration.  If you want to maximize your investment, don’t forget the change.  Ultimately SharePoint is about people and the ability to manage change throughout your organization.

Follow me on Twitter…

August 16, 2010

How to Staff Your SharePoint Project


Something that has been truly bothering me lately is recruiters or project managers or executives not knowing how to staff SharePoint Deployment projects or staff their Operations teams that support SharePoint.   Too often I receive calls from recruiters looking for SharePoint “Technical Resources”.  Rarely are they looking for people who know how to analyze business processes or manage enterprise information management platforms like SharePoint.    It seems recruiters want hands-on resources who write code and do everything else including administration and configuration.   Unfortunately looking for a jack of all technical trades is just not the best way to minimize risk when it comes to your enterprise application deployment.  I’ve seen too many implementations that have gone wrong or ended up simply re-creating the information mess that already existed in the organization.

So let me outline the resources required for ensuring success of your SharePoint implementation.   It is important to note that these resources do not simply go away once you have completed phase I of your global deployment.   Each one will be required for ongoing governance of operations and continued solutions development and support of business needs:

Program/Project Manager – an individual who not only knows how to manage IT projects, but also understand ECM, information architecture, software and solutions development, IT infrastructure, etc…   They don’t have to know how to write code or know SharePoint administration hands on.  They do need to have some “technical acumen” but they also need to evangelize the solutions to both end users and senior executives.  They need to know how manage and govern an application like SharePoint and have discussions about backups,restores, failover, disaster recovery, taxonomies, etc.  They also need to understand communications, collaboration, knowledge management, business process improvements, ECM, web 2.0 — all the capabilities that an organization might leverage with SharePoint.

Systems Analyst – Having the word “SharePoint” on this resource’s resume is just not required.  There are sooooo many GREAT system analyst resources that I have met who seem be stuck in their current role between IT and the Business.   Perhaps they’re in a Big 4 Consulting firm doing QA work on some legacy or ERP application or custom web development for some large Fortune 500 client, drafting business requirements documents, or working late nights with offshore development teams.  All of these individuals I’ve talked to seem disenchanted with their current role, see little career growth, are tired of their current technology focus, and are looking for the chance to work with an application that the sex-appeal of SharePoint.   It really doesn’t matter if these individuals know SharePoint or have seen it.   Let me repeat that: It really doesn’t matter if these individuals know SharePoint or have seen it. If they are experienced with any enterprise application, the skills are all transferable.   This role is so critical in SharePoint’s success because someone needs to work with the end users and business to understand their needs, map out the requirements and workflows, wireframe site designs, get hands with SharePoint Designer and do light customization and design of sites, and provide QA.  However, there is no reason why this resource needs to know how to write code.   They just need to interact with the business and developers ensure what is delivered to users has some level of quality and actually matches the requirements identified upfront in the project.   Lastly, a systems analyst is not someone who simply leaves once the initial deployment is completed.   This person will be needed for ongoing requests by the business to develop solutions on top of SharePoint.  So many companies have way too many internal processes that are paper based, inefficient, or handled over email….that a systems analyst resource will be busy for at least the next decade.

Solutions Architect and Jr Developers – Okay, so here are the resource who knows how to write code… .Net, visual studio, etc.   Maybe you offshore development and if you do, that’s fine.   However, you better have really really good system analysts and project managers to manage that development and provide the interface and QA to the business — especially if there are language barriers to manage.   Don’t expect these resources to know how to configure SharePoint, install it, or do any administration whatsoever.   However, it definitely helps if they do and can guide your organization in their deeper taxonomy planning, security, and high-level solution design.  Do expect they know the SharePoint object model, know how the performance impacts of developing point solutions on top of an enterprise infrastructure.

Information Architect – Expert in ECM and information architecture.  You’ll pay a premium for this resource, but it’s worth it.   Most deployments overlook the need for this person.  Maybe they have worked with other ECM applications like Filenet or Documentum.   Knowing SharePoint is useful, but not necessarily a must have.  If they have 10+ years experience with ECM applications, they can learn SharePoint’s model very quickly.   In fact, most Documentum or Filenet or Lotus consultants I know who have 15+ years experience all say the same thing — they’re doing exactly what they did 10-15 years ago — just at an enterprise scale and with SharePoint.

Systems Engineer / SharePoint Administrator – a Windows certified resource preferably.  Someone who knows how to install, configure, secure, troubleshoot IIS, OS, hardware, Virtual images, and network issues and in a global WAN or extended extranet environments.   When users can’t access SharePoint, you will not only need a really competent resource here — but you will be buying them drinks often!

Storage Engineer – your SAN or NAS experts who understand performance and storage considerations mostly around SQL databases unless you opt to store files outside of SQL.

DBA – SQL Server experts who should learn how SharePoint stores data and files, how to care and feed for it, limitations, and even options for storing files outside the database, etc…

So don’t understaff your SharePoint project.   The ROI is real and you’re making a mistake if you think you can offshore everything or pay a junior resource $40 or $50/hour onshore.    While some of these roles might be filled by a single person, you will likely pay more for someone who can wear many hats — and you should pay more for 1 person who addresses multiple needs (that normally would be addressed by multiple resources).   In this world, you get what you pay for….so don’t risk an information mess in your SharePoint deployment.   Get the right resource with the right skills for the right job….and yes, I’m available if you need help!  🙂

Share/Bookmark

 

August 6, 2010

Three Things to Consider in Your Enterprise Collaboration Strategy


This post was featured on CMSWire.com:

http://www.cmswire.com/cms/enterprise-20/three-things-to-consider-in-your-enterprise-collaboration-strategy-008261.php

Many organizations are planning or are already in the middle of deploying collaboration technology to their global organization. Before you go much further, ask yourself if you’ve identified these three elements of your collaboration strategy.

Perhaps you have invested in a single vendor eco-system like MS SharePoint for collaboration and information management. Like most organizations, you are looking for ways to reduce costs, create efficiencies, consolidate multiple repositories of information, innovate, connect people globally, change corporate culture and simplify the end user experience.

However, your executive leadership is not sure if your organization is optimizing the use of this technology and maximizing the return on your investment. If that’s you and your organization, it’s not too late to take a step back and review your strategic objectives and approach.  A solid collaboration strategy encompasses 3 key things:

1. Define the Business Context

Defining collaboration as synchronous or asynchronous is not enough. Making a decision to invest in SharePoint or Oracle or IBM is not enough. Build it and they will come is not enough.

Typically the best approach to deploying any collaboration technology is having a focused business context in mind. Multi-purpose collaboration platforms offer many features and capabilities. Part of a solid strategy is having a focused business context around social networking, team spaces, communities of practice, crowd sourcing, project management, knowledge management, business process management, etc…

You need to demonstrate real business value and evangelize that throughout your organization to further drive adoption and create a perception of collaboration technology as a productivity tool.

Identifying and applying the technology in a specific business context will help stakeholders and decision makers see how this thing called collaboration can alleviate business pain points, surface information and impact employee engagement and morale.

2. Identify the Degree of Openness

Further expanding on the concept of collaboration in “context” is to identify the degree of openness. Is the collaboration external, internal, global or regional, or line of business focused (depending on how your organization is structured)? Security and user access also come to mind here as it’s easy to create a mess of information within these eco-systems combining confidential information with more public content.

Identifying the degree of openness also includes defining your audience, the type of information you plan to collaborate on, and the overall scope of the collaboration. This will help focus your efforts, deployment, or investigation of collaboration technology as these platforms all offer several components from social computing to team sites to portals and workflows.

When you step back and understand the degree of openness, you may also realize that 3rd party solutions for administration or security just might be a mandatory requirement to protect intellectual property and sensitive information.

3. Establish Goals and Objectives

Project management 101 includes determining what success will look like for your organization. Often times when planning projects, goals and objectives tend be high level and don’t really provide a concrete definition of success. Setting the right goals and objectives will ensure stakeholders, decision makers and users are on the same page when determining if the collaboration strategy is a success.

What specific results should users and executives expect to see?

  • Will this solution reduce costs?
  • Provide a competitive advantage?
  • Do your objectives simply focus on just improving collaboration within project management?
  • External collaboration with business partners or clients?
  • Improving employee engagement & morale?
  • Is it to improve the search-ability of information and documents?
  • Enabling compliance?
  • Executive dashboards?
  • All of the above?

No matter how you’ve defined your collaboration strategic goals, there is ONE objective you MUST have as part of your overall strategy: Develop a standard information architecture and governance of the collaboration platform. Collaboration is generally unstructured (compared to traditional and more structured taxonomies of document or knowledge management) and information architecture and governance are a must for any successful collaboration strategy and deployment.

Collaboration is About People First

As a concept, collaboration goes beyond the simple sharing of documents in a team site or a creating a wiki. It can be all encompassing from team spaces, email, web meetings, IM to communities, web 2.0 and more. At the end of the day, collaboration is really a broad spectrum of content creation, sharing and information management.

Multiple technologies from multiple vendors have been used to address this broad spectrum with email being THE main tool Executives and knowledge workers rely on day-to-day (mostly because of convenience, availability and Blackberries).

Collaboration is about people and allowing them to work when and where they want without being constrained by schedules, time zones or geography. Perhaps your organization has invested in multiple tools (from multiple vendors) to address your collaboration needs: You are using SharePoint for project/document management along-side Websphere Portals, Lotus Notes, Lotus Connections/Quickr, or Documentum eRoom.

In the absence of a solid strategy, the risk of failure or creating a poor first impression of collaboration technology becomes even greater which result in workers continuing to rely on email as comfort food.

Is It Time to Step Back?

The bottom line is this “buzzword” called collaboration has shown up on CIO radar screens as a “Must-Do”. Over the last few years we have seen vendors like Microsoft, IBM and Oracle all begin to offer a single “uber” eco-system to manage all of your collaborative needs, artifacts and related information.

As organizations have rushed to implement these all encompassing technologies from a single vendor, they proceeded without a holistic collaboration strategy, believed that somehow platforms like SharePoint would magically improve the current state, or simply failed to leverage all the collaboration capabilities with the right strategy, approach and governance.

Throwing technology at the problem just resulted in another repository, another place to store documents, another place to create a discussion and another mess in which they search for information when collaborating.

In spite of an expectation for a high ROI and a Google or Facebook-like experience throughout the global organization, users remain confused, continue to be overloaded with information, are limited in their collaborative capabilities, and still use email as the primary collaboration tool. If this sounds like your organization, then step back and look at your strategy.

 


Share/Bookmark

August 4, 2010

What is Knowledge Management 2.0?


The following post was also featured as a “Featured Blog” on AIIM E2.0 Community during August, 2010:

Knowledge Management seems to be making a come back.  Like E2.0 or Web 2.0, KM 2.0 seems to be more about aggregating unstructured information with structured data (perhaps in a community, portal, team space, etc…).

Perhaps the explosion of applications like SharePoint have once again made organizations think about how to manage knowledge more effectively and invest time and money into related projects.   While there is a promise that platforms like SharePoint will “do it all”, organizations have to move beyond simple document sharing and leverage these all-inclusive technology platforms as a collaboration system before it can be considered a system of knowledge.  Users need to make the application part of their day-to-day as much as they live in their email inbox.  And administrators and managers of Knowledge/Information Management systems must ensure they provide the right balance of governance, tweaking/development, care/feeding, and obtain the right consulting guidance to optimize the ROI and ensure users view the technology as a productivity tool that enables them to get their jobs done better, faster, and cheaper…..  Then complete eco-systems (e.g. from IBM, Oracle, or Microsoft) can work very very well for communications, collaboration, community, and knowledge in large organization (both inside and outside the firewall).  However, for traditional ECM/RM or larger knowledge management efforts like digital libraries or e-Commerce driven websites, these all-in-one platforms just may not be the best fit (esp. in larger organizations).

The challenges most organizations face with Knowledge Management are the cost of ownership, too many repositories, different taxonomies, and too many places to search.  What we see today is really not any different than back in the 80s/early 90s with companies having 3,4, or 5 different email systems….and they realized they needed to standardize on 1 email system (novell, exchange, or notes generally).

While it seems most organizations finally have a solid handle on email systems some 10-15 years later, they need to now focus on information & knowledge management.  These systems are not well governed and users inside the organization expect a Google-like experience in spite of all these challenges.  Organizations have simply created an “information mess” in a rush to the web over the last decade.   As a result, collaboration remains difficult and KM becomes even more challenging.  No doubt KM 2.0 initiatives will fail today just like in KM 1.0 unless these same organizations think more holistically in their approach.

There is a tremendous economic benefit attempting to cleanup and consolidate different ECM systems into a single vendor platform (for the 80%) with a consistent and enterprise information architecture that organizes collaboration, information, and knowledge.  While I don’t think 1 system will do everything required by the business, 80% is pretty good … while the remaining 20% might require a more unique/tailored technology solution (be it open source or a more pricey ECM solution).


August 3, 2010

Just featured as member of the week on AIIM Communities…


I’ve shared some of my blog posts on AIIM and was featured as member of the week on AIIM Communities:

http://aiimcommunities.org/users/sharepointpmp

Tags:
July 28, 2010

Ultimate Guide to SharePoint Governance – download the outline now.



Share/Bookmark