Before you introduce Microsoft Copilot, get your information in order

There is an understandable attraction in the idea that employees might be able to ask questions about their organisation’s information and receive useful answers without having to search through documents, emails and business systems. Microsoft 365 Copilot makes some of this possible, particularly where information is already held within the Microsoft 365 environment. For a business whose employees spend considerable time finding information, preparing documents or bringing together material from different sources, the potential benefits are not difficult to imagine.

I suspect, however, that many organisations considering Copilot will discover that the technology raises questions about their existing information arrangements that they have not previously needed to answer. These questions are not necessarily new, and most have little to do with artificial intelligence. They concern where information is held, how it is maintained, who is responsible for it and how people determine whether it can be trusted. What changes with Copilot is that information which was previously difficult to find may become considerably easier to retrieve and use, without necessarily becoming any more reliable.

This creates an interesting problem for organisations considering AI adoption. They may begin by asking whether their technology is ready for Copilot, when the more useful question concerns whether their information is sufficiently well organised to support the work they expect Copilot to perform.

The information is there, but is it the right information?

Consider a manufacturing business preparing quotations for customers. An estimator might need drawings, material costs, production information, previous quotations and details of the customer’s requirements. Some of this information may be held in an ERP system, some in SharePoint, and some in correspondence between the customer and the business. Previous quotations might be stored on a shared network drive, while particular commercial arrangements may be understood by the people who regularly deal with the customer.

From the perspective of the organisation, the information required to prepare the quotation exists. The estimator knows where to find most of it and, when something is missing or unclear, knows whom to ask. Preparing the quotation may involve several interruptions, conversations and checks, but eventually the customer receives an appropriate response. The process appears to work, even if the effort required to make it work is not particularly visible.

Now suppose the business wants to use Copilot to help prepare quotations. The attraction is obvious. Rather than having the estimator search through several sources, perhaps AI could retrieve relevant documents, summarise previous correspondence and assemble the information required for an initial estimate. Depending on the systems involved, this might require additional integration, but the general proposition is reasonable.

Access to information is not the same as understanding it

The difficulty is that retrieving information is not the same as understanding whether it should be used. An earlier quotation may appear relevant without revealing that the job was subsequently unprofitable. A drawing may have been superseded by a revision that is stored elsewhere. A material price might be technically correct but no longer commercially applicable. An experienced estimator may recognise these problems because they understand the circumstances in which the information was created and how the business actually operates.

An AI system may have access to the documents without having access to that understanding. The result is not necessarily an obvious technical failure. It may produce a plausible answer using information that was available, while overlooking something that an experienced employee would have considered important. This is why I think we need to distinguish between making organisational information accessible and making it suitable for use in the work.

Information quality is an organisational responsibility

Most businesses accumulate information systems gradually. A shared drive is created because several people need access to documents. A spreadsheet is developed because the existing business system does not quite provide the information required. A new application is introduced to support a particular activity, while the previous arrangements continue because they still serve another purpose. Over time, the organisation develops a collection of systems, documents and informal practices that collectively allow people to do their jobs.

There is nothing inherently wrong with this. Organisations change, and their information arrangements evolve in response to practical requirements. The problem arises when the resulting arrangements depend upon knowledge that is not represented in the information itself. Employees may know which spreadsheet contains the current figures, which version of a procedure should be followed, or which colleague can explain an unusual customer requirement. These understandings become part of the work, even though they may not be documented anywhere.

The knowledge that never gets documented

A person joining the organisation may initially find these arrangements confusing, but gradually learns how to navigate them. An experienced employee can compensate for incomplete or inconsistent information by drawing upon previous experience, informal relationships and an understanding of the organisation’s circumstances. The organisation may therefore function reasonably well without having a particularly reliable or coherent information environment.

Introducing Copilot can expose the limitations of this arrangement. The technology may make documents easier to discover, but it does not automatically resolve disagreements between them or establish which source should be treated as authoritative. Nor does it necessarily understand the informal arrangements through which employees have learned to interpret information correctly.

This suggests that information quality should not be understood simply as a property of individual documents. It also depends upon the organisational arrangements through which information is created, reviewed, updated and used. A document may be accurate when written but become misleading when circumstances change. A procedure may be technically current but no longer reflect how the work is performed. A customer record may contain the correct details while omitting the history that explains why a particular decision was made.

These are not problems that can be resolved solely by making information easier to search. They require somebody to understand what the information is for, how it relates to the work and what responsibilities are necessary to keep it useful.

SharePoint is not an information architecture

For organisations using Microsoft 365, SharePoint is an obvious place to begin examining these questions. It provides facilities for storing, organising, sharing and controlling access to documents and other information. When designed and maintained appropriately, it can support much more coherent information arrangements than a collection of personal folders, shared drives and duplicated documents.

However, I would distinguish between having information in SharePoint and having an information architecture that supports the organisation. The former tells us where information is stored. The latter concerns how information is structured, related, maintained and accessed in support of the activities the organisation performs.

Moving documents does not necessarily improve the work

Consider a business that decides to migrate its shared network drive into SharePoint. The migration may be technically successful. Files are transferred, employees can access them, and the organisation no longer needs to maintain the previous storage arrangement. Yet if the original drive contained duplicated documents, obsolete procedures, inconsistent naming conventions and folders whose purpose was understood only by particular employees, much of that complexity may simply have moved into a different system.

The underlying problem is that the organisation has changed the location of its information without necessarily reconsidering the arrangements through which that information supports the work.

An information architecture exercise should therefore begin with questions about the organisation rather than the available SharePoint features. What activities require information to be shared? Which documents need to be maintained as authoritative records? How do different roles use the same information? What happens when information changes, and who is responsible for ensuring that the people who depend upon it are aware of those changes?

The answers may lead to decisions about SharePoint sites, libraries, metadata, permissions and document management. Those technical decisions matter, but they should follow from an understanding of the information requirements rather than determine them.

There is also a danger of treating information architecture as a purely structural exercise. A carefully designed hierarchy of sites and document libraries may look sensible to its designers while proving inconvenient for the people who use it. If employees continue to maintain separate spreadsheets, save local copies or circulate documents by email because the formal arrangements do not support their work, the organisation may have created a technically orderly system without improving the underlying information practices.

The effectiveness of an information architecture therefore needs to be judged partly by observing how people actually use it.

Copilot changes the significance of existing permissions

Information access introduces another consideration. Microsoft 365 Copilot operates within the permissions available to the user, which means that the access arrangements already established within the organisation become particularly important. Copilot does not simply give everybody access to everything, but it can make information that a person is already authorised to access easier to discover and use.

This matters because access permissions often accumulate in much the same way as information systems. A SharePoint site may have been made widely accessible because that was convenient for a particular project. Employees may retain access to material after their responsibilities change. Documents may have been shared with a broad group without anybody subsequently reconsidering whether that access remains appropriate.

Such arrangements can exist for considerable periods without creating an obvious problem. People generally search for information they believe they need, and they may never encounter documents that happen to be accessible to them but are unrelated to their work. When AI makes it easier to search and summarise information across accessible sources, some of those existing arrangements may become more consequential.

It would be misleading to describe this simply as a Copilot security problem. The permissions were already there, and the responsibility for deciding who should have access to particular information already belonged to the organisation. Copilot changes the way that information can be discovered and used, which can make weaknesses in those arrangements more apparent.

The appropriate response is not necessarily to restrict access wherever possible. Employees need information to perform their work, and excessive restrictions can create delays, duplication and informal workarounds. The more useful question concerns the relationship between information, responsibility and authority. Who needs access to what, for which activities, and under what circumstances? Who decides when access should be granted or withdrawn? How does the organisation know whether its permissions still reflect the way work is being performed?

These are governance questions, but they are also questions about organisational design.

Start with the work that Copilot is supposed to improve

One difficulty with the idea of Copilot readiness is that it can encourage organisations to examine their entire information environment before establishing what they actually want to achieve. A business might discover hundreds of SharePoint sites, thousands of documents and a considerable number of permissions requiring attention. All of these may deserve review, but that does not mean every issue needs to be resolved before the organisation can begin obtaining value from Copilot.

I think a more useful starting point is to select a small number of activities where employees believe Copilot might make a meaningful difference, then examine the information and working practices involved.

Understanding why the work takes so long

Suppose a manufacturing business wants to reduce the time required to prepare its monthly management report. The report brings together information about sales, production, delivery performance and outstanding orders. The manager responsible spends several hours collecting figures, checking inconsistencies and preparing commentary before the report can be circulated.

It would be reasonable to ask whether Copilot could help prepare the report. Before doing so, however, I would want to understand why the existing activity takes as long as it does. Is the time spent finding information, reconciling figures, interpreting results or preparing the final document? Are the source records reliable? Do different departments use consistent definitions? What judgements does the manager make when deciding which variations deserve attention?

The answers could point towards quite different interventions. If the underlying information is reliable but difficult to assemble, better integration or automation might provide most of the benefit. If the report requires substantial interpretation, Copilot may be useful in supporting analysis and preparing commentary. If the figures are repeatedly inconsistent because information is recorded differently across the organisation, the more important improvement may concern the working practices through which that information is created.

The distinction matters because each of these problems can appear to the manager as the same thing: preparing the report takes too long. Yet the causes are different, and so are the appropriate responses.

This is consistent with a broader argument I have made elsewhere about organisational improvement, particularly in The process map is not the work. The documented process, or the visible activity that somebody wants to automate, is not necessarily a complete account of the work being performed. Employees compensate for missing information, resolve inconsistencies and exercise judgement in ways that may not appear in the formal description. Unless we understand that surrounding activity, we risk introducing technology that accelerates part of the process while leaving the underlying difficulties unchanged.

Copilot readiness should therefore include an examination of the work, not simply an assessment of the technology and information systems.

What would a useful readiness assessment establish?

I would expect a meaningful Copilot readiness assessment to establish three things about the organisation.

The first concerns the work itself. Which activities might benefit from AI assistance, and what would constitute a worthwhile improvement? This requires more than collecting suggestions for possible Copilot applications. It involves understanding the information, decisions, exceptions and responsibilities associated with the activities being considered.

The second concerns the information required to support those activities. Where is it held, how is it maintained, and how reliable is it? Is there an authoritative source, or do employees routinely reconcile information from several places? Are important aspects of the work dependent upon knowledge that exists primarily in people’s experience? Which information is accessible through the organisation’s existing Microsoft 365 environment, and which would require additional arrangements?

The third concerns access, governance and continuing responsibility. Are permissions appropriate for the activities involved? Is sensitive information adequately protected? Who is responsible for maintaining the information, and what arrangements exist for reviewing it as the organisation changes? These questions are particularly important where AI may be used to support consequential decisions or where employees could begin relying upon generated answers without examining the underlying evidence.

Five questions to investigate before introducing Copilot

1. Which task are we trying to improve? Identify the work involved and what better performance would look like before choosing a tool.
2. Where is the information for that task? Establish which documents, messages and systems people actually use, and which of them Copilot can access.
3. Who maintains that information? Check whether documents have clear ownership, current versions and sensible retention practices.
4. Who can see what? Review SharePoint and Microsoft 365 access permissions before making information easier to discover. This is not a formal security audit.
5. Who checks the result? Agree how employees will verify outputs before relying on them in operational or customer-facing decisions.

These questions do not produce a readiness certification. They identify what deserves investigation and where changes to information management or working practices may be necessary.

Readiness depends on the work being considered

I would not regard the purpose of such an assessment as producing a general judgement that the organisation is either ready or not ready for Copilot. Readiness is better understood in relation to particular activities and the conditions under which the technology will be used.

An organisation may be well placed to introduce Copilot for one activity while needing substantial preparation before using it for another. That is not necessarily a contradiction. Different activities depend upon different information, involve different levels of judgement and carry different consequences when something goes wrong.

The useful outcome is therefore a practical understanding of where Copilot could contribute, what would need to change before it could be used effectively, and which improvements would be worthwhile regardless of whether Copilot was introduced.

If these questions reveal difficulties with SharePoint, information ownership or everyday workflows, Cernwell’s Information & Microsoft 365 service can help investigate the causes and agree proportionate improvements. You can discuss a defined project directly; a preliminary assessment is optional.

Preparing for Copilot may reveal a more valuable opportunity

There is a tendency to evaluate AI adoption in terms of the benefits delivered by the technology itself. We might measure the time saved preparing documents, the number of questions answered or the reduction in effort required to find information. These are reasonable measures, provided they tell us something meaningful about the performance of the work.

However, I think there is a potentially more interesting outcome from examining an organisation’s readiness for Copilot. The investigation may reveal that the business has been carrying substantial costs associated with its information arrangements for years, without those costs being particularly visible.

Employees may spend time checking which version of a document is current, asking colleagues to explain information they cannot find, correcting inconsistencies between systems or maintaining spreadsheets that compensate for gaps in formal processes. These activities may be individually small, but collectively they can represent a considerable amount of work. They may also create dependencies upon particular employees whose knowledge is essential to keeping the organisation functioning.

Improving these arrangements can produce benefits that have little to do with AI. Information becomes easier to locate and maintain, responsibilities become clearer, new employees can understand the organisation more readily, and managers can make decisions with greater confidence in the evidence available to them.

Copilot may strengthen those benefits, particularly by making well-managed information more accessible and useful. But the value of improving the information environment does not depend entirely upon adopting Copilot.

This is why I would be cautious about beginning with a technology-led readiness checklist. Technical preparation is necessary, and Microsoft’s guidance on information governance, permissions and deployment provides an important foundation. Yet those arrangements exist to support organisational activity, and their effectiveness ultimately needs to be understood in that context.

For a manufacturing SME considering Copilot, the most useful first step may therefore be to examine a few important activities, understand how information moves through them, and identify the points at which people spend time compensating for deficiencies in the existing arrangements. That investigation can establish where Copilot is likely to help, where other forms of improvement would be more appropriate, and what needs to change before the technology can be used responsibly.

The objective is not to make every document perfect or to reorganise the entire business before introducing AI. It is to understand whether the organisation’s information arrangements are supporting its work as effectively as they should, and to make deliberate decisions about where technology can improve them.

In that sense, preparing for Copilot is not simply an exercise in making information available to an AI system. It is an opportunity to examine how information supports the organisation, and whether the work itself could be done better.