File upload is the most common way users contribute content to SharePoint. Here we are mostly referring to ad hoc user-driven file upload, but the mechanism can also be used in bulk either by a user or by an unattended script.

Users are most accustomed to browsing to a local file location, selecting the file, and uploading it to a designated space in SharePoint. It is one of the slowest capture processes, but it usually results in the greatest quality of content and metadata.

Primarily performed as a singular activity, based on immediate needs to share or manage a document collaboratively with other users, the file upload method is rarely used to bulk load content into SharePoint. Although users might attempt to do so, it is not recommended.

Document uploading can happen by both browsing to a local folder or network directory and selecting a document(s) to upload. In addition, users can simply drag files onto the document library web interface.

Organizations can elect to automate the initial load of content into SharePoint, leveraging either Windows PowerShell scripts or migration tools. In later chapters, we will explain both the risks and the benefits of this approach.

One key element of the manual document upload is the process from the users’ perspective. Where are they finding the content? My Documents? A Shared drive? This could highlight some issues that you certainly don’t want transferred over. What are they uploading? Certain file formats don’t belong in ECM, so do you allow your users to upload anything they have access to? What metadata must they complete for a successful upload? We will address these issues in detail in the next chapter.

Office documents are a born-digital method of capture. These documents have never known a physical existence. This comes with a lot of advantages. This is when a user creates a document in the Microsoft Office suite (PowerPoint, Word, Excel, and so on), which supports the saving of documents directly into an accessible document library.

The advantages of the born-digital method are improved capture accuracy and, most importantly, ease of use. In this mode of operation, SharePoint libraries are “save as” locations for content. Using Office as a client application to contribute content to SharePoint is also a solution that most end-users embrace, because it’s similar to how they have always worked with content.

This encourages knowledge workers to adopt habits leading them away from the storage of content in “My Documents” and “Shared Drives,” which is one step closer to better capture. However, this approach works best when knowledge workers are located within the corporate firewall that is connected to the farm 24/7. Lapses in connectivity can cause problems with upload, versioning, and, more painfully, user adoption.

Proper user training can help with this, and SharePoint “Workspaces” is another alternative. Workspaces is a client Office application that allows content saved in a specific location to be automatically uploaded to SharePoint. Conversely, it allows the viewing of SharePoint Libraries as a folder on your desktop. This is very similar to “Explorer view” and, for the purposes of this book, is considered the same tool.

While Workspaces and “Explorer view” can be used for project portals and personal file repositories, they should not be used for ECM. From a technical point of view, the functionality in Workspaces actually allows the bypassing of proper ECM functionality such as managed meta data columns. From a strategic point of view, if you offer users Workspaces, they are encouraged to live in a My Documents type structure and not a proper ECM. Give the users Workspaces, and you will never be able to take it away.

While many Office documents are manually created, we recommend coaching users to create documents in Office that are saved directly to SharePoint Libraries or, even better, to create content by using built-in Office Web Applications.

The second type of born digital document is the native SharePoint document. Native SharePoint documents are those documents created without the use of an external client. They very often are Office documents with the addition of blogs, wikis, and pages. For documents, this is done using a feature in SharePoint called Office Web Applications OWA.

SharePoint now supports the authoring of documents directly in the browser. The majority of the required functionality found in Microsoft Office client applications can be found inside the browser, making content capture of 90 percent of documents very easy to perform directly in SharePoint. Today, this is not the most commonly used form of capture; however, it is the future and the desired method to guide users toward.

As we look to the future of ECM, natively born-digital documents will take over, shortening the time to capture, increasing the accuracy of content capture and its metadata, and being more acceptable to end-users. The challenge of this approach is to make sure that an organization is current in browser and operating system support.

We now move to types of Capture that are more use-case specific and sometimes omitted by organizations.

Electronic form submission is one way to get user content into SharePoint. The process enables individuals to complete online forms often referred to as e-forms, and the results of form submission are saved directly to SharePoint. The person completing the form very often will not have access to the form submission content nor necessarily be a named user in SharePoint.

The preferred approach to electronic form submissions in SharePoint is the Microsoft product called InfoPath, because it is a tightly integrated electronic form solution. However, it is also possible to leverage third-party or custom e-form solutions. We will include references to additional resources that can be used for e-form solutions in SharePoint later in this book.

One of the most neglected aspects of form capture is form design. Without good electronic form design, the information entered into the form rapidly diminishes in quality. Because electronic forms are one of the best ways to capture structured information and metadata, we encourage organizations to spend considerable time on the usability, presentation, and transformation of their forms.

For purposes of this book, discussion of the specifics of e-forms and InfoPath will be omitted. Rather, forms will be highlighted as a way to get content into SharePoint.

Often, documents are not born digital. They begin as physical entities, but they need to be a part of the ECM system just as critically as born-digital documents. The process of capturing this content is called document imaging or document scanning.

This process occurs in three primary ways: ad hoc, departmental/distributed, or production capture. The process also can include image-only capture or capture with intelligent conversion technology.

The owner of the content at their client workstation performs ad hoc capture with an attached document scanner. Departmental/distributed capture is an extension of this, but shared document imaging stations are usually shared among several knowledge works. Finally, production capture focuses on centralizing all capture operations, controlling the indexing, and performing advanced processing and data collection functions in a predictable manner.

How organizations pick one type of capture over another depends on the document maturity of an organization or their own structure. Later we will go into detail about how the various types of capture can be incorporated into SharePoint. While SharePoint does not have natively built-in scanning functionality, there are several ways to incorporate ad hoc and departmental scanning. Production scanning is often considered as a process outside of SharePoint.

Sometimes content is not created by a user but rather by another system. “Integration” is a rather broad term that describes connecting disparate systems. For purposes of ECM, we will define a specific type of integration where only content and metadata are transferred from outside SharePoint into SharePoint and refer to it as content streams.

A content stream can come from any electronic source and is defined as the ingestion or publishing of metadata and content via some standard such as Windows PowerShell, REST, XML, and RSS. An example would be the consumption of news feeds inside of a SharePoint page or the publishing of RSS feeds for a list to be consumed by another system.

The functions are broad, covering many different methods for integrating the capture of content in SharePoint. The most important thing to understand is the necessity and governance of such integrations and how it relates to the other forms of capture. For example, surfacing documents that live in another content system impacts the way an organization will plan their ECM environment and train their users.

After content is captured, it has to be properly stored. This moves us to the Store process.

Often, Information Architecture is confused with one of its individual components, such as folders or site collections, rather than looking at it holistically. We find that while many organizations implement Information Architecture organically, very few know what it is. We can visualize all aspects of Information Architecture in Figure 1-3, showing that this is the logical location of content in SharePoint. The figure shows, in a hierarchical order, all aspects that define the logical storage of a document and how its metadata is represented. In later chapters, we will define each of these and their use in detail.

The growing trend is to make the repository portion of Information Architecture as flat as possible and the metadata portion as comprehensive as possible. Later in the book, we will talk about the theoretically ideal Information Architecture and align it with practical implementations of SharePoint. We will come up with guidelines for designing your Information Architecture.

Figure 1-3. Information Architecture.

We dare to suggest that Information Architecture is not only the place where you will spend most of your time in planning a good ECM solution, but also a place where you can have fun. For those who strive to be organized, Information Architecture is where it happens.

In contrast, the use of proper metadata in content types instead of folders allows a user to slice and dice content on any number of combinations of information they want. Metadata provides a more flexible means of organizing and reorganizing content on the fly. Surfacing content in visual folder layouts is acceptable, but it must be used in conjunction with metadata and search.

As documents come in to the right location, in the right format, they often need to be versioned.

Versioning is the process of storing earlier versions of a document with their associated time and date stamps. The earlier versions might be used to revert back to previous version, for comparison across versions and for sharing one version while a more current version is still being edited. This is not to be confused with tracking changes in a Word document; tracking changes is a function that facilitates the creation of versions, but it is not a version control system. In SharePoint, versioning can happen automatically. When a document is saved, it is possible to save a major version or a minor version. The versioning number system is what determines whether it’s major or minor. A minor version is everything to the right of the dot or decimal, and the major version is everything on the left side. For example, a document with version 3.5 has a major version of 3 and a minor version of 5.

Because major and minor versioning is usually used only when an organization publishes documents—for example, to an extranet or partner portal—the major version represents the published version while minor versions remain unpublished and continually edited. So while editors are working on version 3.5 and on to 4, the people who have access only to published versions see version 3. When versions are saved, the editor has the ability to add comments to help identify what changed in the version. Some versioning happens upon document upload and is automatic, based on filenames that already exist.

There are two dangers of versioning. The first is blindly enabled versioning, which could result in the overwriting of files without the users knowing. The second and more serious danger of versioning is the impact it has on content databases by adding a separate copy of the document and additional comment metadata. This can cause a site collection to get too large too fast.

One of the huge benefits of the SharePoint Platform is that anything and everything can be content. Besides file size limitations per file, there is no limitation on the type of file you can upload to SharePoint. However, there are best practices for choosing which file formats to support as a policy. The considerations are based on how functional the files are, how they can be viewed or edited, and whether they pose any security risks.

The most common formats used are MS Office documents and PDF files. But it’s not uncommon to see media files, CAD files, and other proprietary file formats. Another part of file formats in SharePoint is a mechanism called iFilter. The iFilter is what makes content useful to SharePoint. It exposes the internal content of the document in a way that SharePoint can index and search on it. It also is necessary for third-party products that run within SharePoint to visualize, edit, or otherwise work on the content.

As we indicated in the From the field sidebar on formatting, transformation, while not always a consideration, often becomes an important consideration when it comes to the types of file formats you allow and the desired formats to have in the ECM system.

Transformation, also referred to as conversion, is the process of taking an original file format and converting or transforming it into another. The transformation process often is just a format change, but it can also include other processes, such as optical character recognition, natural language processing, translation, and other types of content manipulation that make the resulting document more useful. SharePoint has some built-in conversion functionality for Office documents and hooks to incorporate other transformation processes.

You now have the documents captured, properly stored in a content database in the right filing location according to your Information Architecture. You have them in the right format with versioning capabilities. Guess what? This is starting to look like a real ECM system. Now let’s work on managing the content that has found its way into SharePoint.

Records management, like its broader parent, ECM, is a practice and methodology. However, records management requires a far more strict set of principles. Records management includes the following disciplines:

A record is a stamp in content, time, location, and metadata for a document. When a document is declared as a record, its content will not change; the metadata, such as last modified data, will not change; and its logical and physical storage location will not change. Very often, there is an additional step that occurs during records declaration, which is a reassignment of security so that individuals who don’t have authority cannot access the records.

In the past, SharePoint records management was limited only to record centers. A records center automatically declares all documents as records when they are saved in that site collection designated as a records center. However, now with SharePoint 2013, records declaration can happen in a records center or in any other library automatically, via a workflow, or with manual in-place records management.

Records and non-records alike might be subject to retention schedules. A retention schedule is a listing of all document types and their associated life spans. For example, a contract might be deleted five years after the termination date. Retention schedules are required in compliance-driven industries but are not common in smaller business. However, the use of retention schedules is an excellent discipline for any organization and can be a cheat sheet for implementing ECM in SharePoint.

Records management, even when implemented, does not apply to all content. The relevant content is determined by the retention schedule and is usually critical to business operation or contains potential risk/value associated with compliance or litigation. Organizations, even without records managers or records management policies, can choose to learn from the strict organization principles so that the can be better prepared for future compliance restrictions or litigation. The retention schedule also determines which elements of metadata are required or not. This particular practice of deciding what metadata is required or not, while mentioned here in records management, is mandatory for all organizations.

In your organization, it’s not the content you know about that can hurt you; it’s the content that you don’t know about.

Another huge benefit to SharePoint is its ability to manage security at nearly any level. What you learned above about Information Architecture is an absolutely critical element in security considerations. The various site collections, sites, and libraries will all have separate security considerations.

Access levels are among those considerations. Who has access to what? Similar to Information Architecture, the hierarchy of security can spiral out of control. Security and access levels have a direct one-to-one relationship. For example, even though item level security can be achieved in SharePoint, the maintenance and risk of such a policy is high. Also, as with Information Architecture, the trend is to make security envelopes at the top level and flatten and widen the repository where security restrictions are applied. For example, instead of having a site collection for all departments and a site below it per department, organizations are making a site collection per department, with security at the site collection level instead of the site level.

SharePoint has the ability to show to users only content they have access to and also block users out of a repository completely, if necessary. This process is called security trimming and is a tremendous tool that you can use to help protect content and support compliance initiatives.

Security is one way to enforce governance, but it does not solve everything.

There are certain elements to governance that can be implemented with technology, some can be implemented only with rules, and others could be accomplished with either technology or written rule, so a decision must be made. For example, “management by the red asterisks” is the process of making certain metadata fields required for document upload. But this can encourage users not to use the system when over used, so it might be better for an organization to declare to its knowledge workers which metadata is required and which is not.

A policy is a written rule on how to use the system. What is written in a policy is one thing, but how the policy is implemented is far more important. Most policies will also need to have specific procedures and, in some cases, user training to make sure policies are understood. Policy is usually set at an executive, board, or steering committee level. The department management and knowledge workers familiar with the business process generally develop procedures. A policy that is simply published without documented procedures, training, and, ultimately, enforcement is rarely effective. Therefore, part of a policy system must include the enforcement system. What we mean when we say this is that if you are going to make the policy, you have to take action when it’s broken or the policy’s value is nullified.

Organizations might want to believe they can do without policy and utilize technology enforcement or rely on the better judgment of their users. This will ultimately lead to great adoption in the wrong way or to no user adoption at all. Not considering the policy system can result in ECM failure.

When an organization decides to take on a project like SharePoint, the requirements will slowly evolve with time. They actually start to evolve as soon as the project starts. However, if your organization is similar to others and plans for all adaptations along the way, you will be crippled by planning and ultimately finish nothing. There has to be a system that prepares for changes in requirements, technical environment, and business environment so that these changes do not halt the deployment of a system, prevent its adoption, or prevent its extensibility into future solutions for an organization.

Change control is the process of managing this change. In any system, the life of the system can be impacted heavily by change in organization structure, staff, or even just focus. Change control is the tool used to mitigate these negative impacts on the system so that they don’t accumulate to reduce the life of the system. In ECM, change control starts at the project kickoff and lasts throughout the life of the system on to the next one. It defines the roles, what happens when a change to the system is requested, and who is responsible for the longevity of the system.

By its very definition, ECM is global in scope, so most business systems and processes have an impact on other departments in one way or another. Truly understanding the impact that poor change management can have is usually felt when a system goes down or a process fails. This happens for a variety of reasons, and we have all been there when things go bad due to a random change made without planning, approval, and documentation.

Search is the processes of using keywords or Boolean logic to locate content and information. The process of search is to issue a query and to review a set of results to determine an appropriate item. While the actual search query feature is fairly basic, the tools that isolate the correct piece of content or, even further, the correct page in the correct content are very complex. Such features include best bets, search refiners, and relevance.

Search can be both a positive and negative indicator. The more often that users find what they are looking for will imply that the Information Architecture is perfect. Also, the fact that you can search across the enterprise is empowering and reduces the time it takes for you to get to content. Therefore, search and Information Architecture are intimately tied and share joint planning. They are so tied, in fact, that they share components. Facets, also referred to as refiners, are components of Information Architecture as well.

The goal of search is to get users to content faster. Search can start out with very basic principles but quickly evolves to topics such as thumbnails, best bets, in-page relevance, and so on. Whatever the cool components of search, the end game is always the same: get the user to the right content with the fewest clicks.

After a user finds the document, either via search or browsing, they have to be able to view and edit it.

While users don’t often realize where they spend their time or why they do what they do, a simple study will prove that users spend most their day in some sort of viewer. A web browser is a viewer, Outlook is a viewer for email clients, and SharePoint is a viewer for content. An amazing amount of time is spent reading and consuming content as compared to creating it. Most job functions spend the majority of their time consuming rather than creating, while other specific audiences, such as technical writers, business analysts, and publishers, spend a lot of time creating and editing. For this reason, the ability to do this seamlessly is critical.

With the exception for records and archived documents, the majority of content is living. It gets edited and viewed on a regular basis. SharePoint has built in viewers for Office documents. This allows you to work with the documents in the manner in which you are accustomed. For other varied file formats, a different type of editor might be required. It’s important in the planning process to understand how content will be consumed, edited, and repurposed.

You need to understand that viewing and editing ties heavily to the formats discussed in the Store stage of ECM. The fewer types of documents, the easier it is for organizations to creating great editing and viewing tools for them. The Office suite has the clear advantage of having essentially bundled viewing and editing capabilities with SharePoint, either with client applications or with Office Web Apps. Documents such as PDF, which is predominantly designed for viewing and not editing, have special considerations when it comes to ease of access. For example, do you allow users to open the PDFs in the browser or client application, or do they have to download to their local machine first?

While the aspects of viewing and editing seem obvious, its considerations are not, which is why it’s an essential component to ECM planning.

Publishing, which contains aspects of both search and viewing, is the process of pushing content or allowing content to be pulled, by individuals who are not necessarily the curators, for viewing purposes only.

Publishing incorporates versioning in the storage stage, formatting, and ease of access either by targeted search or great Information Architecture. Usually, publishing also includes portals that are branded with basic themes or other more complex branding to make it a great landing page for content consumption. These portals are called intranets or extranets. Content on intranets and extranets is usually read only and comes from another location within the ECM system. This book will discuss in detail creating and managing content for publishing, or rather, the locations from which content is pushed. It will not cover in detail the configuration and branding of such intranet and extranet portals.

The most common example of process is referred to as approval workflows. This is the process of routing a content item or transaction through a series of predefined steps for approval between different layers of management. This is very common in Human Resources, Finance, and Procurement.

For purposes of this book, workflow describes a process that contains one or more states or steps, incorporates user and system tasks, and is routed in a single direction. The purpose of workflows is to take metadata and content and turn them into action. A SharePoint workflow requires an existing business process to be well understood and defined. In most cases, work just gets done, but the flow of how that is accomplished is not documented or fully understood by all knowledge workers. To facilitate that process from beginning to end, there are user driven activities, management decisions, and transactional exceptions that need to be reviewed and completed. Workflows are very high-value items to automate, but most organizations underestimate the amount of due diligence required to prepare for a workflow automation project.

In ECM, the considerations around workflow are not just the content that is moved around via workflow but the steps and considerations of the content flow itself.

Business Process Management looks very similar to workflow, but it differs in that it allows for multidirectional processes, ability to version processes, and change control for processes. It is said that workflow is available out-of-the-box with SharePoint, but BPM usually comes via third-party solutions. The biggest technical difference is not just the workflows that can be created but also the management of those workflows.

In later chapters, workflow and BPM will be discussed together with the assumption that the user is performing out-of-the-box SharePoint functionality.

After content has been captured and processed, gaining insights from the content is a great way to take their value even further. Business intelligence (BI) is a broad category of technology that extracts greater value from content.

The bridge between BI and BigData is very strong. Therefore, we have lumped them together. Both increase the value of the data and assume some sort of structure and good metadata. Arguably, BI is a subset of BigData, although BigData implies manipulation of large datasets, whereas BI could be big or small. We illustrate this in Figure 1-4 by showing content actualization, starting with the most complex and highest cost and moving toward the most commonly used to achieve tangible business value.

Figure 1-4. Content actualization.

BI really falls into the following three types:

Today, most people refer to BI as the ability to visualize large amounts of data in a graphical way, such as a graph. These are referred to as Dashboards or Key Performance Indicators (KPIs). They are fed by structured content, but unstructured content can be incorporated by using technologies such as Natural Language Processing, Text Analytics, Auto-Classification, or incorporating search into the analysis.

User-driven Business intelligence in SharePoint manifests itself as Excel spreadsheets and, more popularly, the PowerPivot add-in for Excel and SharePoint that allows a user to manipulate data in three dimensions or cubes.

Data mining is the most advanced and expensive use of BI. SharePoint can certainly be a source of information for advanced data mining tools but does not natively have data mining tools.

Arguably, BigData is just another definition of, or a broader definition of, a business system that includes and implies larger data sets and the use of a new database approach called NoSQL. Again, SharePoint does not have native BigData support, but it can certainly be used as a source for BigData third-party tools.

A very specific type of processing of content is called eDiscovery. This particular process is one that organizations hope to avoid. Not only is the process of audits, litigation, and so on painful to the organization, the cost of such processes when not planned for is phenomenal.

When planned for, this cost can be dramatically reduced. And the process of planning for eDiscovery, fortunately, is the same as all aspects discussed in search and Information Architecture. Why? Because eDiscovery is essentially search combined with records management.

eDiscovery seems like some abstract term, but it really talks about an advanced form of search. In a later chapter, we will go into more details about what eDiscovery is, how it’s used, why it’s used, and how it works in SharePoint. eDiscovery is the identification, isolation, and locking of any content that pertains to a matter. The most common instance of a “matter” is litigation. However, a matter could relate to the Freedom of Information Act, content audits, and so on. After eDiscovery is run and content is identified, it must be isolated and separated from content not associated with the matter. The relevant content must be held as a record so that it is not updated or modified, which would make its value null.

It’s safe to say that delivery and process are the areas we all enjoy the most when it comes to consuming content. It’s also the area where the greatest investments and advances in technology are happening. The goal of ECM is to get users to spend more time in the Process stage and less in the Capture, Store, and Preserve stages of ECM.

It is very common to reformat content when it’s preserved. Ten years ago, the trend was to convert content to microfiche, but today it’s PDF/A. The purpose of reformatting is to ensure that it’s not editable and to ensure that it can be viewed in the future. The reformat process also includes the purging of unnecessary versions and metadata. In addition to reformatting, many organizations also choose to compress their content.

Reformatting also has the consideration of viewing. How can you be sure that the content you have preserved can be viewed in the future? This is where librarians and content preservationists excel.

One major consideration for reformatting is the size of files. There is a process of compression that is often considered for reducing the size of files prior to final preservation. The problem is that it’s rare to find compression technology that does not alter the content of a document during the compression process. Lossy content, or content that loses quality each time it is converted and/or compressed, is similar to the result of taking a picture of a picture. Over time, information is lost, and the possibilities for editing, consuming, and repurposing content in the future diminish with each iteration.

Compression is just one type of transformation process that is commonly used in ECM. This process reduces the file size of a document without loss of integrity of the content. With graphics, compression can reduce the quality of graphics, but the content of the documents remains. Compression becomes significantly important when discussing ways to save space and archival processes.

Overall, preservation is not all too common, and as the cost of storage reduces and technology for managing content improves, it becomes less and less common. For that reason, preservation will be referred to in this book as a possible end to a document’s life in SharePoint, using such tools as RBS and SendTo locations.

It’s rare for knowledge workers without the skill set of content management to be interested in ECM without a reactive driver. However, you might have departments or managers that promote a culture that values organization. And from the perspective of being organized, they embrace the methodologies of ECM. Ironically, it’s also these departments and this culture that resist change, because they very often have a well-established system for filling content and are not much interested in taking that away.

Another area where organizations are proactive is when ECM has a direct impact on operational costs. This is most often where content touches a line-of-business application. This can be found in health care, insurance, accounting and finance, banking, and so on—that is, organizations where everything has a process and there is content involved. The benefit of these organizations is that they usually already have a retention schedule and content that varies very little in topic, so building an ECM solution is very simple.

And finally, there are the select few, like the book’s authors, who love the idea of getting content under control so that greater value can be attained. It is our goal that some readers of this book will finish in this category. Now let’s talk about those reactive drivers which are a more common catalyst for ECM.

Reactive organizations have faced some negative event where the cost of poor ECM was evident. The most common such events are litigation and compliance, where a company was the defendant or claimant in a lawsuit. I’m sure that you can spot something in your organization where you can’t help but laugh at the way things are done. At some point, these areas of operation, you hope, are addressed with new approaches.

The second most common is compliance driven. A good example is if your organization operates in an industry that is compliance-heavy, like health care, insurance, or banking. These industries deal with a tremendous amount of regulatory burden. In fact, many of the legislative actions taken to create regulations like SOX (Sarbanes-Oxley), HIPAA (Health Insurance Portability and Accountability Act), and Dodd–Frank (Wall Street Reform and Consumer Protection Act) contain very specific provisions that can be complied with by using components of an ECM solution.

The benefit of the later reactive scenario is that very often, in such cases, the implementation of ECM is very clearly defined, and it’s more a matter of conformity. Most often, these organizations, due to their history in the industry, already have a good sense of what needs to be done, and their business challenge is adoption rather than implementation.

For the reactive scenario in litigation, these organizations very often were not aware of what was wrong until it hit them. The process of getting content associated with this litigation is called eDiscovery. Later in this book, we talk in more detail about eDiscovery. The cost associated with eDiscovery is phenomenal. Therefore, to be better prepared and to mitigate these costs in the future, organizations are deploying proper ECM solutions and participating in what is called early discovery.

The reactive scenario is not what the world of ECM hopes companies are using as their primary driver for implementing ECM. The hope is that organizations are thinking about what it takes to best actualize content, get the most value from content, and to make their knowledge workers as effective as they can.

This scenario is very rare and usually combined with one of the above reactive scenarios. There are a handful of organizations who believe that if they better capture, store, and deliver content, their costs of working with content will be reduced, the effectiveness of their staff increased, and finally, that they can move that content into more valuable decision-making processes, such as workflow and BigData.