Sean R. Nicholson

It never ceases to amaze me how few people trust their organizational intranets. A tool that was designed specifically for the purpose of helping employees do their job better and faster is often the joke of the water cooler. Yet organizations knowingly ignore the fact that employees don’t use or trust the information stored on their intranet.

Periodically, I have the great opportunity to sit in front of a group of employees and ask them about their intranet experiences. Often, it’s in anticipation of an intranet revamp, so the need for a “do-over” or an evolution has already been defined at some level. While the individual users and comments might be different, they usually go start with something like this:

Me: Who here uses the Intranet fairly consistently?  (half the hands in the room go up).

Me: For those of you whose hands aren’t up, why don’t you use it?

Response #1: The content stinks.

Response #2: I can never find what I’m looking for.

Response #3: Yeah, and when you do find something that looks right, it’s two years old.

Response #4: The last time I searched the intranet for the latest information on new Java libraries, the first five search results were the hours and

specials at the local coffee shop.

Me: For those of you with your hands up, (you can put them down now) tell me how you choose to use the intranet?

Response #1: I use the employee directory. It’s right most of the time because it’s tied to our active directory and employees are added/removed as they join or leave the company.

Response #2: I use it to see what’s being served in the cafeteria. They do a good job of updating the menu each morning.

Response #3: I used it to download the forms to change my 401(k). I did have to choose between last year’s forms and this year’s forms, but I navigated directly to the HR landing page, and didn’t use the search tool.

…and the conversation goes on for another hour. Each employee sharing their stories of frustration or limited successes with the intranet platform. One failure feeds another employee’s stories and the negative sentiment in the room grows. Frustrations often include multiple logins, confusing navigation, multiple windows, and ugly design but the vast majority of their frustrations are around the relevancy of content, outdated information, and poor search results.

Now, imagine for a moment that, instead of the corporate intranet, these comments and stories were being said about another employee. If an employee had a history of providing inaccurate information, was behind the times and slow in their responses, and didn’t collaborate well with other employees it’s highly likely that they wouldn’t survive their next performance review. Yet organizations continue to ignore the fact that a tool that is key to their business success is unable to provide employees what they need. In fact, many companies invest more money in licensing fees and servers for their Intranet than any single employee in their company. Yet, the investment in keeping the content fresh and relevant is minimal. When you present your Intranet in this light, it seems like a logical deduction that an annual review of the performance of your Intranet is worthwhile.

The conversation continues to get more interesting as the focus shifts toward what the employees would like from their Intranet:

Me: First, are you interested in having a functional Intranet? If so, why?

Response #1: Definitely! It would make my job a lot easier if I could find updates to our products and pricing easily.

Response #2: Not really, we purchased a different tool for our group to store information because the Intranet is is bad.

Response #3: I would use the Intranet if I knew the search worked. Right now, it’s just too hard to navigate around a hope that I find what I’m looking for.

Response #4: I think a good Intranet would really help the company do business. It just needs to be a lot easier to use. No one asks the employees how they want it to work, they just give us a tool and say “Figure it out”.

Response #5: They should probably just start over and build something like Facebook. I’m already friends with most of my co-workers, anyway, so it would be easier if we could just make a private place on Facebook where we could share company information.

From these responses, it clear that the desire for an intranet exists in some format. Even responses #2 and #5 indicate that there is a need for a tool, they just opted to use something else or want a different tool since the organizational intranet wasn’t meeting their needs.

Steps To Develop Organizational Trust In Your Intranets

1) Ask Your Employees For Input

Most employees that I talk to feel like they have no ownership or input to the Intranet. They view it as a tool that is given to them by the organization and its structure and content are set in stone. They are, however, interested in making it a better tool and have plenty of input on how to improve it. Some of the input is good, some of it is wishful thinking, and some of it is so focused on their specific job that it may not be useful to others. Little changes to navigation and content, based on their feedback, does increase positive sentiment and gives employees a sense that they had an impact on organizational change.

2) Give Employees The Chance To Shape Content

Because content woes are top of the list when it comes to frustration with their intranet, many employees would welcome the opportunity to contribute content or, at the minimum, provide feedback on the value of the content. Although most aren’t interested in writing blogs, they would like to be able to suggest content or changes to ensure that information is accurate. To accommodate this, feedback forms, commenting systems, and content rating tools can help employees flag or suggest content. By providing these tool to employees, organizations remove the excuse that “content isn’t useful” and put the onus on the employee to shape the quality of the content.

3) Conduct Scheduled Content Audits

Empowering your employees to help shape the quality of the content doesn’t mean that employees responsible for maintaining the Intranet can sit back and relax. Consistent auditing of search logs to find failed searches (those with zero results returned) can help determine a need for creating or re-purposing content. In addition, face-to-face conversations with your employees to ask what they would find valuable can result in a gold mine of  content requests. Obviously, the need to evaluate future functionality is a key responsibility, ensuring that employees are armed with tools and features that will help them in their daily activities.

4) Optimize Your Pages To Work With Your Search Engine

Although it’s tempting to blame the technology behind poor or failed search results, it’s usually not the intranet search engine that’s causing failed searches. Instead, it’s likely poor search optimization or old content that results in failed searches and employee frustration. Taking some time to understand the fundamentals of search engine optimization and tuning your pages to meet the search patterns of your employees can make a huge difference, without having to rip out and replace your search engine.

Just like any employee in your organization, neglect of your Intranet will result in poor performance and dissatisfaction. If you’re really interested in improving your business processes, doing more with less, and helping your employees do their job try investing a little more time and energy into ensuring that your content is good and is able to be found.

EAVB_ZUCRRVMRCL

Sean R. Nicholson

Continuing with my posts on great Twitter resources, this is a followup to my 99 Great Internal Comms Resources,  99 Great Intranet Resources and 99 Great ECM Resources posts. Below is a link to my list of 99+ great SharePoint Resources on Twitter. If you’re looking for the folks who tweet about SharePoint as an Intranet platform, ECM solution, and a collaboration tool…these are your folks! Pay careful attention and you may see folks who are also providing links to some valuable SharePoint alternatives, as well.

Sean’s list of 99+ Great SharePoint resources on Twitter

Know someone that I missed from the list? Definitely let me know. Shameless self-promotion is also allowed if you think you should be included, just make sure your tweets back up your request.

You can check out the list below, and feel free to leave a comment if there’s anyone else I should add.

Sean R. Nicholson

Last week was a great week for online discussions relating to Intranets. On Monday, Alex Manchester of Step Two Designs posted an article to his blog asking whether the term Intranet is dead. His thoughts were sparked by a recent presentation by Jane McConnell of NetJMC and the conversation that ensued was a healthy dialog on the future of Intranets, their relevance in a world of social media, and whether the term “intranet” was really the best way to describe an interactive workplace. The conversation continued throughout the week and I’d encourage anyone who works with Intranets to check out the threaded discussion and add their $.02.

Tuesday continued the interesting online conversations as Jarrod Gingras and Alan Pelz-Sharpe of CMS Watch made his predictions for technology in 2010. One of particular interest to me was his prediction #1 that :

1) Enterprise Content Management and Document Management will go their separate ways
ECM as a marketing and technical concept has great validity. But the idea of having a single overarching platform to manage all sources of content management only works well in those enterprises that follow a unified and services-oriented architectural approach to IT.

I agree with Jarrod and my interpretation of this prediction is that organizations that aren’t able to settle on a single vendor for all of their information systems or aren’t able to invest in a comprehensive services-oriented architecture just won’t be concerned with Enterprise Content Management (ECM) because they won’t be able to address every departmental business process problems with a single ECM tool.

To expand on Jarrod’s prediction, I’m thinking that as more and more vendors build document management functionality into their applications, organizations will be less concerned with where it is stored, as long as it is stored properly, is accessible to the end-users that need it, and can be discovered and produced in time of legal necessity. Instead of costly redevelopment of business processes to restructure where content is stored, organizations will invest in search technology that allows content to be stored in native applications and use search tools like Microsoft Enterprise Search, Autonomy, and Google appliances to ferret out information.

In other words, federated search will become crucial to organizations that choose not to implement a structured ECM architecture.

The results of this kind of shift are as follows:

1. Content and documents  will reside in their native application, allowing the information to have more context than if it were stored in a centralized ECM system.
2. Those ECM vendors who wish to provide value to the enterprise must figure out how to store the content centrally, yet serve it back to end users in a context that is meaningful to their end users.
3. ECM vendors who provide true, enterprise-scale software MUST offer a full services-oriented architecture that will allow business applications to easily access the content and surface documents in the context of the business application.

S0…this brings me to my question of the week. Is Enterprise Content Management going the way of the Intranet and becoming an outdated notion? Will better federated search technologies negate the need for a central repository? Are organizations better off investing in the functional elements of ECM like document management, records management, and business process management instead of buying the whole enchilada?

I’m curious to see what others think…looking forward to thoughts/comments.

Sean R. Nicholson

In the second article in this series, we’ll focus on understanding Content Management and how it differs from Document Management and Knowledge Management. If you recall from the first article in the series, Document Management is all about how we create, manage, route, retain, and destroy the container that we refer to as a document. Content Management, on the other hand, focuses primarily on the information stored inside that container and how you can effectively add/edit/delete the information in the document.

Keep in mind that while some folks use the term “document” generically to refer to Microsoft Word documents (primarily because they use the .doc extension), a document can also be an PDF file, an HTML file, a Microsoft Excel spreadsheet…really any kind of container that holds content.

Distinguishing Between Pure Content Management And Enterprise Content Management (ECM)

Note: Before we dig into the details of Content Management, we need to establish that the focus of this article is to define and discuss pure Content Management separately from Enterprise Content Management. ECM blurs the lines between Document Management, Content Management, and Knowledge Management which, when brought into the conversation,  makes it difficult to discuss each of the separate components on their own merits. So, for the duration of this article, take a step back and let’s just focus on the Content Management component, apart from ECM. In the final article in the series, I’ll bring it all back together to discuss ECM.

So What Is Content Management?

In it’s simplest term, content management is simply editing a document to add, replace, remove, or modify the content. When you open a new Microsoft Word document on your desktop and type a few lines of text, you are engaging in content management using MS Word as the content management tool. You then save the document and store it on your computer, network location, or document management system. Through this process, you have engaged in both document management (the creation and saving of the document) and content management (the adding of information inside the container). Simple, right?

Content Management becomes much more challenging for organizations when you ask many people to collaborate at the same time on the same document. Issues arise such as the following:

• How do you keep one person from overwriting the content that another has added?
• How do you keep people from corrupting documents by editing them at the same time?
• How can you control the quality of the content to ensure proper spelling and grammar?
• How do you audit when someone last edited the content?

The existence of these, and many other issues has driven the creation of tools that allow organizations to collaborate around content, aka Content Management Systems. By introducing functionality such as user accounts, authentication, check in/check out, change tracking, and rich text editors (aka “WYSIWYG”), Content Management systems have addressed many of the concerns created by mass collaboration by limiting what individual contributors are allowed to do with the content and tracking when content is being edited. By leveraging this added functionality, organizations can minimize some of the risks of mass-collaboration and can maximize of the benefits that content management tools offer.

Different Kinds Of Content Require Different Editing Tools

In their early days of distributed content management, CMS tools focused primarily on editing Web pages. These Web Content Management systems allowed non-technical users to create, edit, and publish content to corporate Web sites and Intranet portals without having to know HTML, JavaScript or any other coding languages. As a result, organizations were able to empower their business users to take ownership of the content in their Web site and Intranet portals without having to engage IT for each and every change. In addition, the use of user accounts allowed organizations to control which roles were allowed to create content, edit it, and approve for publication.

Because of the proliferation of these tools and the rapid organizational adoption of them, the term Content Management System became synonymous with Web Content Management System. But as organizations saw the value of these systems and a variety of different types of content were introduced into the enterprise, new content management tools were needed.

For instance, digital assets such as images, videos, Flash movies, and audio files presented new challenges. To maintain the quality and appropriate use of these corporate assets, Digital Asset Management Systems were created to all organizations to manage the assets in a similar fashion to managing documents, while allowing some content management functionality through plugins with popular editing software like PhotoShop and Flash.

Document Management and Content Management Come Together Through Business Process Management

As the ability to edit different types of content has grown, organizations have recognized that the content management and document management can be intertwined to improve on business processes. Business Process Management tools provide organizations with graphical workflow solutions that allow for the creation and routing of documents from one user to another. upon arrival in their workflow queue, users can edit or review the content using a content management tool and then finalize the document or route the document to another user or queue for further processing.

Business units like Accounts Payable, Human Resources, Contract Management, and Decision Support have optimized document and content management by applying automated business rules that allow the document to be management in a specific manner based on the content.For instance, in situations where an invoice has a low total amount (say under $500), an organization can auto-approve the payment of the invoice without a high level of risk. In situations where total invoice amount exceeds a threshold, the workflow can route the document appropriately for a content review to ensure proper auditing.

Bringing Content And Documents To The Users Through Knowledge Management

The process of creating documents and managing their content continues to become more difficult as the volume of information in the organization grows. Effective organizational content and document management strategies are going to have to find ways to get the right information to the right user. To do this, business process tools and content management systems are going to need to leverage knowledge management principles to evaluate content and route content appropriately.

In the next article in the series, we’ll take a look at how Knowledge Management principles can be used to ensure that content is being effectively reviewed and used in the organization.

Sean R. Nicholson

Document Management, Content Management, and Knowledge Management are three very nebulous terms that get thrown around a lot when discussing the functionality and requirements of an Intranet. Unfortunately, concrete definitions of these terms are hard to come by since the terms often mean different things to different organizations. In an effort to build a common understanding of the terms, let’s break down each of the terms and look closely at how they inter-relate. The first article in this series focuses specifically on Document Management.

Document Management – Capturing, Storing, And Routing Containers Of Information

Document management is a common term that most folks in today’s workplace are familiar with. Think of all of the Microsoft Word, Excel, and PowerPoint documents that you have stored on your local workstation. By simply creating, storing, and deleting those documents you are engaging in the simplest form of document management. Simple, right?

The complexity of managing documents grows significantly, however, when you have hundreds or thousands of document creators in the same organization. As the number of documents needing management grows, issues such as the following arise:

• Where do we store all these documents?
• What happens if we don’t centralize them and someone loses a workstation? Can we replace those documents?
• What security risks are presented by allowing documents to be stored on workstations?
• How do we find the documents that we need?
• How can we secure documents so that only specific individuals or groups can see them?
• How do we keep people from recreating the same document over and over?
• How do we move documents from person to person electronically?
• Is there a way to make documents go away automatically according to our retention schedules?

If you take a look at those questions, they primarily focus on how you manage the container we call a “document”, not the content inside of it. In most cases, the content tools used to create and edit the information inside the containers has been selected. ..these tools are the Content Management tools, which we’ll discuss later in this series.

Document Management Systems vs. File Shares

So when thinking about documents and the document management needs of a large group of document contributors, organizations often look for ways to store the documents centrally, pass them around the organization, secure them appropriately, and discard them when their useful life has expired. Organizations usually look to file shares (a virtual drive mapped to your computer often designated with a letter like your “F: drive”) to serve as their initial document management system, and they do serve a useful purpose…up to a point.

For small groups file shares provide a common location to save and share documents. A document creator saves it to a folder in the share and then tells others about it by either sending the link on the share via email or verbally. The difficulties with file shares present themselves as the number of users relying on the documents grow. Common issues include:

• Difficulty in applying permissions to specific documents. File shares do folder permissions well, but not file-level permissions.
• File shares do not allow for check in/check out functionality.
• Searching across file shares can be a slow process as the number of folders and documents increase.
• Documents get “stale” if the owners do not constantly update or clean up their documents
• The size of a file share can quickly get out of hand if no one monitors that number of documents that are stored there

As a result of these deficiencies, growing organizations sometimes break apart these file shares into logical clusters like an F: drive for marketing, a G: drive for Sales, and a T: drive for IT. The problem, however, is that this practice now silos documents and makes them difficult to collaborate around. When the Marketing person can’t access the Sales share, the answer is to attach documents to emails and send them, which creates a nightmare as to which version is most current, how are changes to documents merged into the parent document, and more. What happens is that growing organizations usually outgrow file shares relatively quickly and look to Document Management Systems to bring that decentralized information back together to provide a common management system.

What Do Organizations Look For In A Document Management System?

In response to the shortcomings of file shares, the requirements usually sought after in enterprise-level document management systems often look something like:

• The ability to store documents in a variety of formats captured from imaging devices, created by desktop productivity applications (e.g. MS Office), and generated by other enterprise applications.
• The ability for administrators to define and enforce a common folder structure (often referred to as a taxonomy).
• The ability for end-users to add documents and sub folders to the repository using a browser-based interface or integration with productivity applications like Microsoft Word or Excel.
• The ability to move documents from user to user using workflow capabilities.
• The ability to perform full text searches against the documents in the system.
• The ability to remind users to review documents on a periodic basis to keep documents up to date.
• The ability to delete documents from the system according to a retention period.

Again, the focus is primarily on the capture, storage, and management of the containers. With the exception of being able to search the content and sometimes route through workflow, document management usually doesn’t really focus on what’s in the document, just that the document can be stored, moved around, accessed, and managed.

When organizations start looking at the content inside the document and how to create, review, and update content the focus often shifts from document management to content management, which leads us to the next topic in the series.

COMING SOON – Document Management vs. Content Management vs. Knowledge Management  Part 2 – Understanding Content Management

Sean R. Nicholson

A few years ago, I was in charge of an RFP for a Fortune 500 company to select an Intranet portal application and portal content management system. Thinking about the requirements for that portal and how they would change in this age of social networking got me thinking about how the requirements would change if I were to conduct that same RFP today.

Portal Requirements in 2005

Back in the “olden days” of horizontal portal requirements (you know…a few years ago),  the top requirements for our enterprise portal were as follows:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide a WYSIWYG rich text editing interface that allows users to create and edit content, based on their permissions and group membership.
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide a workflow tool that allows content to be reviewed and approved prior to publication
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. The ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.

Like I said, these were the high level requirements that we looked at. We actually had more than 300 specific technical and functional requirements, but these hit the major functionality we were looking for.

As you can see, though, these portal requirements are based on an “information-push” concept, where a core group of individuals (maybe 50-75 for the entire corporation) create all of the content and push it out to the masses. While we did have requirements for collaborative items like forums, they were listed as optional and we weren’t quite sure whether we wanted to allow end-users to start creating content on their own in a forum environment. Pretty much typical information control tactics that are present (even today) in many large organizations.

Changes To The Portal Requirements In 2009

While many of these requirements would still hold true, an information portal in today’s culture would definitely focus more on collaboration and content management than the pushing information out to the masses. Based on my experiences with some of the popular social networking platforms, my top requirements for the same sized organization would probably look more like this:

1. Enterprise scalability, with current requirements at 25,000 end-users, but scaling to 100,000 with additional hardware and licenses.
2. Easy to use, graphical user interface that allows end users to view targeted content and easily navigate to pages within the portal using  either an organizational or functional page taxonomy.
3. Provide portal administrators with the ability to secure content to groups, organizations, and individuals.
4. Provide both a rich-text content management system that allows portal administrators to deliver content and a WIKI environment that allows end-user to create their own page content
5. Provide a single search interface that allows users to search for content that is target to their account based on assigned permissions
6. Provide content creators (both in the CMS and WIKI environments) the ability to review content additions and comments if they choose to enable the feature.
7. Provide a customizable portlet or widget-based interface that allows end-users to customize their experience.
8. Provide portal administrators with a flexible design and administration interface that allows administrators to create page templates that standardize on some page elements (e.g. header, navigation, mandatory portlets).
9. Provide functionality to interface with an enterprise Identity Management Solution.
10. Provide analytical reporting that details usage activity, content quantity, and hyperlink status (e.g. number and location of broken links)
11. Provide the ability to integrate with existing enterprise applications such as the document management system, time reporting system, and expense management system using a Services Oriented Architecture.
12. Provide end-users with the ability to create custom application and information widgets that can be shared across the enterprise.
13. Allow users to easily share updates with others on their work through personal status updates
14. Allow users to create and manage groups/networks that can collaborate through a WIKI interface or a discussion forum interface. Users should be able to store and review documents as attachments within these groups. Users should be able to collaborate and version these documents and the applications should maintain an audit trail.
15. Allow users to create custom events and invite users and groups to those events. Individual and group events should roll up to a common corporate calendar that displays events to users based on their permissions and group memberships.
16. Allow users to share digital media including photos, audio files, and video files. Users should be able to collaborate and version these files and the application should maintain an audit trail.

So What Just Happened? Those Don’t Sound Like Portal Requirements!

Basically, in the process of writing those new requirements, I changed my RFP from being one focused on a portal, to one focused on an Enterprise Content Management system. Not an ECM as we know it today (which are primarily focused on Web/Intranet content management, document management, and digital asset management), but to an ECM platform that requires the following:

• A customizable presentation layer (the portal)
• A flexible content management system (traditional WYSIWYG content management and collaborative WIKI)
• The ability for end-users to create application mashups
• A lightweight document management system
• Social networking capabilities through collaborative groups/networks
• A lightweight digital asset management system
• Enterprise search functionality

Previously, ECM players such as Stellent, Documentum, and OpenText have not offered a portal interface to their products. Instead, they focused on their ability to interface with portal such as WebCenter Interaction (formerly AquaLogic User Interaction (formerly Plumtree)), IBM WebSphere, Microsoft SharePoint, and Vignette portal.

As a result, some of those solutions are being gobbled up by the portal players in hopes of creating the true Enterprise Content Management System of the future. Some of the portal players, like Vignette and Microsoft have anticipated the merging of portal and CMS, and have opportunities to add social networking to their platforms. In the end, the days of offering a standalone portal are probably long gone and we’ll soon see the horizontal portal players roll into the ECM magic quadrant.

Thoughts or comments? I’m always open to additions and constructive criticism in you comments.

Sean R. Nicholson

A couple of years ago, I was involved in the selection and construction of a new Intranet portal for a large telecom company. The organization had nearly 25,000 employees at the time, distributed all over the United States and they had previously relied heavily on an Intranet portal to communicate corporate events, share HR information, and collaborate on business documents.  The project I was working on at the time was focused on creating a brand new Intranet portal for a spin-off company.

One of the most memorable moments of the project occurred during one of the initial funding conversations, when a Senior Executive at the company asked a very simple question. Amid all of the discussions about functionality, Identity Management, timelines, user adoption, and vendor selection, the Senior Exec simply asked “Do we really need an Intranet portal?”  The question was powerful enough to quiet a room of 25 people and, for an uncomfortable 30 seconds or so, I mentally wrestled between blurting out a visceral response like  ”Are you kidding?” and taking a more tactical response explaining the value of a portal. Luckily, while I was pondering the choice, one of my IT Execs jumped in and provided a quick, concise answer as to the value of the Intranet portal, which was good enough to get the funding conversation back on track. Eventually the project was funded, proved to be wildly successful (on time and under budget is always a good thing), and that particular Senior Exec got to fully realize the value of the portal in ways that had not previously been used in his organization. I still kick myself every once in a while for not having an “elevator speech” response prepared for the occasion.

How often do we question the value of the technologies we support?

An interesting aftereffect from that meeting, however, were that rumors of the conversation quickly spread throughout our IT organization. I can’t tell you how many times I got on an elevator with other IT professionals and, after a few moments of silence, one of them would turn to me and ask ”So…do we really need an Intranet?”.  We’d have a good laugh and part our separate ways on different floors.

To this day, I often reflect on the power of that simple question. The more I think about the situation, the more impressed I am with the fact that one person, in the midst of turbulent conversations had the courage to ask the simple question of “why”. Too often in IT, we press forward with technology, especially when it comes to legacy systems, without asking why we’re doing it. Sometimes we feel like we’re trapped by a proprietary platform, or maybe our end-users are resistant to change, so we simply pour money into costly upgrades or development efforts without raising our hand and asking “Why?” or “What is the alternative?”.  Different options always exist, so in these rough economic times, maybe it’s an ideal time to take a closer look at the technologies that are fueling your organization, compare them to the feature-functionality of new products, and determine whether a new product could actually do the job better for cheaper…or maybe whether you actually need the technology at all.

The second reason I often think about that situation has to do with a mindset of automatically assuming that the technology we advocate for is invaluable to the company. Regardless of whether your area of experience is Intranet, Business Intelligence, Data Warehousing, CRM, or any of the other IT realms, you need to be prepared for the question of “Why”. As your business partners begin to look for places to cut costs, reduce their overall application portfolio, or move to a Software as a Service (SaaS) model, you need to be able to realistically justify the technology you support.

To that end, here are my top 10 justifications for a corporate Intranet portal. I’d be very interested to hear additions that readers feel are important.

1. A centralized location for corporate communications – This is more important to larger organizations than it is to companies of 25 employees. The larger and more distributed the organization, the more important it is to the corporate culture to have a single place where all employees can go to find information on company strategies, announcements, HR information, and special activities.
2. Application and information aggregation - There is nothing more frustrating to employees than to have to open 15 different browser applications and 10 different application clients to find the information they need. Employees (especially those facing the customer) need to find information quickly and almost need the information to find them. Case in point, one of the more recent Intranets I worked with allowed the employees to look up a customer by name in the Intranet portal. The resulting page created a mashup of application information including links to the customers service contracts, open service tickets, and even a Google map of where the customer was located with the closest service technician shown on the map via an integration with a Global Information System (GIS) application. All of this information came from several different applications, mashed into a single view of relevant information.
3. Federated Search – A good Intranet portal offers a federated search model, allowing end-users to use a single, simple search interface to find information stored in a variety of applications. For instance, the portal should be able to leverage APIs from the corporate HR system, document management system, as well as CRM and ERP applications. The value of locating information stored in disparate systems makes a strong business process improvement case for the ROI of a portal.
4. Identity Management (aka “simpler sign-on”) – Modern portals provide a single point of entry to corporate applications and information, so they should either include an Identity Management (IdM) solution, or leverage a third party system. To ensure a high rate of user adoption, end-users should be required to authenticate as few times as necessary to support corporate security policies. This “simpler sign-on” schema reduces the number of times a user has to log in, saving time, and enhancing employee satisfaction.
5. Knowledge Management and Collaboration - Through the use of collaboration tools such as knowledge bases, Wikis, forums, chat rooms, or blogs, Intranet portals capture the corporate knowledge of how things get done. These collaborative tools ensure that commonly repeated solutions are captured in a searchable manner that can be discovered easily by future employees. In addition, these tools mitigate the danger of allowing knowledge to “walk out the door” when employees leave the company.
6. Decentralized Content Management – Intranet portals with integrated security and content management systems allow each department within the organization to manage their own content creation/management strategy. Long gone are the days where every article published to the portal had to be scoured and approved by a Content Manager in Corporate Communications. Instead, the Corp Comm group often establishes guidelines and best practices for the departments (and sometimes at the individual level) to follow. This allows for information to flow more freely within the organization and updates to the content to made in a more timely manner.
7. Organizational Transparency (aka “silo-busting”) - An added bonus to the decentralization of content management is a transparency factor. The more content that is published by each department, the better the chance that the rest of the company will gain an understanding of their goals and strategies. This helps drive cross-departmental communication, reduces the amount of overlapping work being done, and drives organizational collaboration.
8. Environmental Sustainability – More information stored in electronic format that is easily searchable naturally results in fewer file cabinets full of paper. Intranet portals can serve as document repositories for smaller companies and integrate with third party document management systems in larger organizations. The end result is less paper, and a better solution for the environment.
9. Employee Satisfaction – The easier information is to find, the more likely an employee will be able to resolve the business problems they face in their daily duties. Whether it’s locating customer information in order to resolve a customer issue, or locating research information that the employee can leverage in their next presentation, the more business information that is available throughout the organization, the better decisions employees can make in their jobs and the more successful they will be.
10. Customer Satisfaction – Last, but by no means least, is customer satisfaction. By centralizing information and providing access to federated search tools, customer-facing employees can reduce the amount of time it takes to locate customer information and can make better business decisions that reduce call handling times, increase first-call resolution in call centers, and lead to upsell opportunities that provide customers with enhanced services that meet their needs.

Sean R. Nicholson

Over the last few years, the term “Enterprise Content Management” (ECM) has become a term familiar to those working in the Intranet, Web, or Knowledge/Information Management sectors. The difficulty lies in the fact that, while the term is easy to toss around, the actual definition of what is expected to be encompassed by ECM continues to evolve. As a result, ECM to a Records Manager often means something very different than what ECM means to a Web Developer. In an attempt to more accurately define ECM, this article deconstructs the term into a variety of subcomponents that are commonly included in discussions about ECM.

Core Functionality for ECM

Recently, when conducting a search for an ECM solution for a Fortune 500 organization, the following core requirements were set forth as required elements to participate in the selection process. These core components provided a basis for what was expected to be included in an ECM offering:

• Document Management (DM) – Centralization of millions of documents was core to the functionality of this particular business and document management is probably the most consistent component in the definition of ECM. In this case, the DM system was required to have a browser-based folder view of the repository as well as check-in/check-out document collaboration, robust full-text searching, and the ability to secure documents at the organizational, folder, and document level. In addition, the solution required full auditing capabilities of each user and object within the repository. Finally, integration with the enterprise email system, while not required, was favorable.
• Web Content Management (WCM) – Although the goal of this particular RFP was to select a content management system (CMS) for an Intranet portal, the principles were the same as the selection of a Web Content Management System.  The solution had to include a “What You See Is What You Get” (WYSIWYG) rich text editor that allowed content creators and managers to easily edit and permission content. In addition, the solution had to offer the ability to schedule content for future publication.
• Records Management (RM) – To comply with the corporate retention schedules, the RFP required that the selected solution provide Records Management functionality that included the ability to schedule the review and destruction of items marked as corporate records. The ideal solution would allow for the creation of a variety of retention categories that allow for the movement of corporate records from real-time storage, to secondary, and eventually tertiary storage as the lifecycle of the record progressed.
• E-Discovery Tools – With E-Discovery weighing heavily on the minds of corporate attorneys everywhere, it was required that the selected solution provide the ability to locate content based on keyword searches or metadata and place those documents or records on legal hold for review. These documents, while in hold status, would be exempt from the records retention/destruction policies. In this case, the E-Discovery tools were only required to access content and not data. The distinction is that the ECM tools were focused on content stored in document and portal/Web content repositories and not in application databases such as customer relationship management (CRM) solutions or billing systems.
• Enteprise Search Integration – To provide a single search interface to users, the solution was required to provide search integration through an Application Programming Interface (API) using the Web Services Definition Language (WSDL) or other suitable messaging platform. The implication was that users should be able to search many sources of content using a search interface integrated into the corporate portal.

Just to participate in the selection process, each vendor was required to demonstrate that they offered the above functionality. That doesn’t mean, however, that these five elements completely defined ECM for that organization. Even after the solution was selected and implemented, the definition of ECM continued to evolve as users identified new content types and needs. Discussions of blogs, Wikis, and digital assets identified new potential content and required the reshaping of how content would be captured, stored, and governed. As this evolution progressed, several additional components were added to the organizational definition of ECM.

Secondary Functionality For ECM

• Transactional Content Management – Activities such as claims scanning and processing, invoice processing, and human resources employee packet processing all require that data be captured via scanning or electronic methods, and processed through a workflow until completed.
• Business Process Management - Activities that require documents or content to be passed through a workflow needed to be automated using a business process management tool. These tools allow the Business Process Owner to lay out the business process in a graphical manner and then create worflow rules that govern the routing of the document or content to various roles in the organization. The classic example is that of the content creator/editor/approver. The content creator creates the content and then routes the content item to the editor queue for editing and review. Once the content is edited, the editor forwards the content item to the approver for final review and publication.
• Digital Asset Management – In this age of digital media, the protection of electronic assets such as coporate logos, images, videos, and audio files is becoming of increasing concern to organizations. Digital Asset Management (DAM) systems focus on securing and protecting those assessts, restricting whether they can be used, duplicated, or altered by users and tracking when those activities occur.
• Knowledge Management – Knowledgebases, Wikis, blogs, microblogs, forums, and mashups are surfacing more frequently in the enterprise and the content created by their authors is key to capturing information once trapped inside each employees head. Using these tools, content authors can share their experiences and understanding of the organization. Each comes with its own challenge, however, as the content is often controlled by the creator and often has not review process.

Clearly, to this organization the definition of Enterprise Content Management went far beyond the ability to simply store a document in a centralized location and locate it when necessary. Just as in this example, organizations are continually being challenged to define what should be included in their Enterprise Content Management solution. As new types of content are identified, the need to store, secure, and locate them becomes more and more crucial to business operations. As a result, the definition of ECM will continue to evolve and the solutions offered to manage these content types will be required to either specialize in specific aspects of the content or grow to become all-incluse of the various content types.