| 3.1 Change Manager
17. Document Naming Convention | |
|---|
| 1. Document Naming Convention | | 1. To understand that a benefit of working with a large number of customers for the last twenty years is that many different document naming conventions have been analysed so the most effective convention can evolve by continual improvement. | | 2. To accept that it may not be practical to impose a document naming convention, but it is reasonable to share what may have evolved as the very best document naming convention in the world. | | 3. To understand that a consistent organization wide document naming convention is needed so documents can become an intellectual property asset, rather than a loose collection of personal documents. | | 4. To accept that what has been personal "documents" and "files" for the last twenty years will become valuable reusable "web pages" in the next twenty years. | | 5. To help approved people to name documents according to an agreed consistent organization wide convention that all parties understand and can use. | | 6. To eliminate each person inventing their own unique document naming convention that can only cause confusion for other people with a loss of precision for the organization. | | 7. To build document search and retrieval into the document naming convention so people enjoy a more productive experience when looking for critical business information. | | 8. To build a productive and efficient means to search for documents by words in the document name. | | 9. To understand that "document name" means "file name" or "folder name" - may also mean "site name" and "container name". | | 10. To dictate that documents are the legal intellectual property of the organization where the name of each document must conform with the business rules defined by the organization - democracy will not apply. | | 11. To expect collaboration to become a major productivity benefit where documents are not owned and edited only by one author, but shared and edited by many people in different places so the document name must become meaningful to teams of people. |
| 2. Character Set | | 1. To treat documents as a type of web page that will be shared and reused for the next twenty years. | | 2. To form document names with upper and lower characters, numbers, hyphens and underscores. To generally use underscore separated words so search and retrieval can be applied in a consistent way. To use the underscore (_) to delimit every different part and the hyphen (-) to separate multiple words within the same part. To accept that this convention may be reversed when the keyboards used prioritise the hyphen over the underscore. | | 3. To eliminate the use of spaces and symbols in a document name that will not be compatible with web page URL name rules. | | 4. To minimise the use of upper case so document retrieval can be based on lower case words. To capitalize the first letter of every word is an option. | | 5. To avoid using spaces in document names because they cannot be included into a URL except by replacing each space by a "%20" - making the file path hard to read and search. | | 6. Incorrect: | | * Company group invoice 1.pdf ( URL= ...\Company%20group%20invoice%201.pdf ) | | * RedMail SharePoint 2019 Trial Version V.3.pdf ( URL= ...\RedMail%20SharePoint%202019%20Trial%20Version%20V.3.pdf ) | | 7. Correct: | | * CompanyGrp_INV_01.pdf ( URL= ...\CompanyGrp-INV-01.pdf ) | | * RedMail-SP13_Trial_V03.pdf ( URL= ...\RedMail_SP13-Trial-V03.pdf ) | | 8. To never use an appostrophe in a word - document names are a list of search terms that may not be grammatically correct. |
| 3. Unique Names | | 1. To accept that if all documents had a title as "document.docx" then the value of the information is lost and the organization would not be able to build up a intellectual property asset. To make document names unique within a context defined by a simple folder system. | | 2. To accept that if all documents had a title as "document.docx" then the value of the information is reduced and the organization would not be able to build up a intellectual property asset. | | 3. To make important information in the document names related but also UNIQUE between themselves. | | 4. For example: if you have a large number of sales or project documents in a library, like invoices, quotations, quality assurance, etc. To consider including to the document name a short description or abbreviation of document "type" like INV - for invoices, QN - for quotations, or QA - for Quality Assurance, followed by a company name and document ID number - this way they can all relate, but every file stays unique. | | 5. Incorrect: | | * Company-Invoice1.pdf | | * Quality-Assurance-Document-Company-5.pdf | | * Company_ClientQuotation.pdf | | 6. Correct: | | * INV_Company-01.pdf | | * QA_Company-05.pdf | | * QN_Company-01.pdf | | 7. To build a unique document numbering system: each invoice must have a unique number, quotations should be numbered, reports should be numbered, tenders must be numbered, every document must be numbered. To build each sales campaign founded on a unique number, to ensure every person, company, project has a unique number, to ensure every asset has a unique number. To define every task, activity, meeting. minutes, event, schedule, list with a unique number based on type. To define every policy, procedure and method with a unique number. To accept that this document is a web page with a prefix of "ITIL" meaning ISO 20001 Information Technology Infrastructure Library. | | 8. To expect that a document such as "Annual_Report" must be defined with a year suffix, regardless of what folder name it may be stored in. | | 9. To understand that "RED", "Red" and "red" are the same document name in most systems and by most archive retrieval and search systems. |
| 4. Sort Purpose | | 1. To build document names with a sortable and filterable purpose. | | 2. To focus on the amount of information used: just enough elements to identify the document quickly and to allow searches to be precise and specific, but not too many that would compromise the retrieval time with unnecessary data. | | 3. Important information should optimize daily processes involving the documents, like: sorting, filtering, and searching. | | 4. In most of the cases, we recommend to include to the name structure some unique document sequences like document number or client IDs. This may help you organize files in a more structured way and find them faster when needed. | | 5. Incorrect | | * Quotation-2015-NewDocument.pdf | | * ProjectCompany-SponsorshipProposal-V1Draft.pdf | | * Company_Group_Germany_Office-Quotation.pdf | | 6. Correct | | * QN_15-0001.pdf ( Type + Year + Document ID ) | | * P023_SP_V01-1.pdf ( Project ID + Type + Draft Version ) | | * CL204320_QN.pdf ( Company ID + Type ) | | 7. Incorrect | | * Invoice-Company.pdf ( Not enough information ) | | * Quotation-Client_Company-2015-n2-Version2.pdf ( Contains unnecessary information ) | | 8. Correct | | * INV_Company_0125.pdf | | * QN_Company_15-002-V02.pdf |
| 5. Short Names | | 1. To understand that short names are faster and more economical to process than long names - productivity and efficiency is founded on shorter names. | | 2. To accept the document name should be as short as possible without losing its potential to be identified and searched - longer file names take more time to read and to remember. | | 3. To remember that documents are a type of web page with the document name part of the link URL - a long document name will generate a long file path, making it more complicated for email sharing - and data excess can slow down the environment performance. | | 4. To know many ways to reduce a document name size: Start by replacing repetitive words with prefixes or abbreviations (e.g. DRG for drawings) and setting up a versioning convention (e.g. v. 01, 02 represents major documents versions, and v.01_01, 02_01 represents drafts of each major versions respectively). | | 5. Incorrect: | | * ProjectCompany-Drawings4-FinalVersion.pdf | | * University of Germany - Payment-2014-Draft1.pdf | | 6. Correct: | | * P025_DRG_004_V01.pdf ( Project ID + Type + Document ID + Final Version ) | | * UniGER_PAY_V01_01.pdf ( Client + Type + Draft Version ) | | 7. To build an organization wide glossary of abbreviations where most subjects can be uniquely identified by three characters. To expect every department, site, office, division, area, airport, depot to have an internal three character code. | | 8. To eliminate the application name or file type being part of the document name such as "Word_List_of_Departments.docx" or "Letter_To_Paul.docx". To eliminate words such as: "of", "the", "and", "as" - document names must be searchable not grammatically readable. | | 9. To eliminate the words "draft" or "final" in the document name - use "V02" as a suffix. |
| 6. Word Priority | | 1. To understand that the order of words in a document name are critical to search, filter and retrieval procedures. | | 2. To accept that the success and value of the document content management system is dependent on the way that document names have been managed. | | 3. To order words in a document name according to the level of purpose from general to more specific, rather than what may be grammatically correct by a local culture. | | 4. To order words in a document name must begin with what may be searched for most - key words are in preferred search order. | | 5. Incorrect: | | * Version2-SponsorshipProposal-Company.pdf | | * 3Quarter-2015-Partnership_Contract-EnovaPoint.pdf | | 6. Correct: | | * SP_Company_V02.pdf ( Type is more general and Version more specific ) | | * JonesPoint_PCT_Q3-15.pdf ( Client is more important for search ) | | 7. To take care with persons names to conform with data protection regulations. To use family name before first name or initials where the name cannot be replaced with a numeric token. | | 8. To know that "StaffTraining" and "Staff-Training" and "Staff_Training" are acceptable, but the use of underscores is recommended. To know that "Staff Training" is unacceptable because it will e changed to "Staff%020Training" when used as a URL web page. | | 9. To use the singular of a word rather than a plural because the singular can always be searched and filtered. To use "Sales_Invoice" rather than "Invoices". To use "Vehicle" rather than "Cars_and_Vans". To use "Person" rather than "People" or "Persons". To never use "User" to mean a person. To use "Phone" rather than "Telephone" because it is shorter and means the same. To use "Review" rather than "Reviews" even when the folder holds many review documents. |
| 7. Two Digit Numbers | | 1. To accept that numbers should normally be defined as two digits because sorting and searching uses left-to-right significance where 9 is higher than 10. | | 2. To maintain a logical version numbering system, begin with V01 and increment towards V99. | | 3. To learn that V1 is followed by V10 before V2 - a level of chaos caused by using a single digit number. To always insert a zero in front of a number 1 to 9. |
| 8. Eight Digit Dates | | 1. To accept that dates should normally be defined as eight digits in the format YYYYMMDD (year, month, day). To enable "20190304" or an alternative as "2019-03-04" to mean 4th March 2019. | | 2. To understand that searching, filtering and display order will only work with a left-to-right convention of year, month and day numbers. | | 3. Incorrect: | | * QualityAssurance-Company-07-04-2015WorkOrder.pdf | | * Fev_10_2019-MarketingMeeting.pdf | | * JungleDocs_Trial-John_Smith-n120.pdf | | 4. Correct: | | * QA_WO_Company_20150407.pdf ( Type + Type2 + Client + Date ) | | * 20190210_Mktg_MTG.pdf ( Date + Department + Type ) | | * SmithJohn_JD-Trial_00120.pdf ( Name + Product + Version ) | | 5. To accept that time should normally be defined as six digits in the format HHMMSS (hour, minutes, seconds). To never insert a colon, space or slash between hours and minutes. |
| 9. Portability | | 1. To plan for documents to become valuable intellectual property that is shared with many other business parties. | | 2. To understand that meta data will be available in the short term, but a valuable document may have a busy life cycle that will not always include its meta data. | | 3. To build into the document name all the data needed to support that document for its entire life cycle - especially when it is in different folders or just a link in an email. | | 4. To accept that a folder system can provide short term context, but for each document to have lasting value, it must have a name that is not dependent on its folder names. | | 5. To design document names as web page names: unique, meaningful, searchable, sortable, filterable, short and portable to any computing device. | | 6. To understand that the past 20 years of deep sub-folder systems will give way to a more flat structure where documents take priority and folders reduce in significance. To know that in many cases it is the folder structure that gets in the way of finding critical documents that can be lost or mis-filed. To learn that less sub-folders is more productive, more efficient and more effective. | | 7. Incorrect: | | * .../JonesDocs/Documentation/Report/ExportSPLists.pdf | | * .../SalesDocs/Quotations/Clients/Company/151002.pdf | | * .../JonesPoint/Site/Blog/Articles/DocManagPart02.pdf | | 8. Correct: | | * .../JonesDocs/JD_DOC_Report_ExpSPLists.pdf | | * .../Sales/QN_Company_20151002.pdf | | * .../JonesPoint/Blog_ART_DocManagP02.pdf |
| 10. Automation | | 1. To help people create meaningful document names by applying a tiny bit of automation that generates a consistent name based on a few key words used to define the document. | | 2. To understand that not all people are able to remember all the document naming conventions and new people may have strange naming ideas that they learnt at school. | | 3. To provide a set of business rules that can be used with a key word form to automatically generate the document name. | | 4. To see Eliza as the artificial intelligent assistant that will apply document name business rules on behalf of the organization. |
| 11. Summary | | 1. To avoid long document, folder and file names, but to make short document names rich in information. | | 2. To avoid deep folder systems where documents may be lost or mis-filed - complex sub-folder systems are the root cause of most performance issues. | | 3. To provide document names as a set of underscore separated words where each word is provided in search priority order - from the general to the specific. | | 4. To see Eliza as the artificial intelligent assistant that will apply document name business rules on behalf of the organization. |
| A1. Meta Data | | 1. To understand that every document must have a set of meta data - data about the document. | | 2. To ensure that every document has a unique name so it can be searched for by name and can be presented like a web page with a unique URL link. | | 3. To operate a unique document reference numbering system so each document can be linked by number, no matter when the document moved to any folder system. | | 4. To provide a document description that is a readable synopsis. | | 5. To provide a set of document key words that enable the document to be discovered by key word. | | 6. To provide a privacy statement that implies role, security, priority and life cycle. | | 7. To manage the issued date and the last date (and time) that the document was changed. | | 8. To manage an edition or version number as a major-minor pair of numbers. | | 9. To record the authors name (or pseudonymised token) and the name of each person who applies a change. | | 10. To comply with UK laws where every document has an assigned deletion date when the document will be destroyed. |
| A2. Life Cycle | | 1. To accept that it may be the responsibility of nobody to delete obsolete data, yet that obsolete data is a liability and cost on the organization. | | 2. To ensure that every document has a defined life cycle with a potential destruction date - everything in the universe has a life cycle and a destruction date. | | 3. To replace personal responsibility to destroy with automated business rules that destroy documents when they are no longer an asset and have become a liability. | | 4. To grant the author of the document the right and responsibilty to vary the default life cycle of a document. | | 5. To see Eliza as the artificial intelligent assistant that will apply document destruction business rules on behalf of the organization. |
| A3. Version Control | | 1. To know that version (edition) numbers (major.minor) must be built into every living document where collaboration is involved. |
| A4. Folder Structure | | 1. To design a shallow folder structure where document contents tend to be of one file type - all PPTX presentations will be in the folder named "Presentations". | | 2. To identify that the organization chart defines a folder structure that is a recommended high order system to represent: area, site, branch, office, department. | | 3. To accept that each department operates in a different way, but as a generalization, each department may do business with: people (staff), customers, suppliers, projects and assets. | | 4. To define the third level as functional such as: tasks, events, meetings, quotes, invoices, payments, expenses, activity, message, inspections, reviews, appraisals, presentation, evidence - in practice these are just types of tasks as things people do. |
| A5. Limits | | 1. To understand that computers have limits and limits change over time. | | 2. To avoid symbols other than underscore and hyphen. To ignore upper and lower case and treat the whole of a document name as if it was lower case. | | 3. To accept that document names should not exceed 250 characters. To know that each space in a document name has a length of 4 characters. | | 4. To accept that folder names should not exceed 250 characters, but the combined length of a folder and document name must not exceed 400 characters. | | 5. To expect that OneDrive-for-Business as a SharePoint Online Site will be able to synchronize up to 22 thousand document names and store up to 30 million documents - most documents cannot be synchronized - these limits will evolve. |
| A6. Sovereignty | | 1. To take care that data sovereignty is understood, documented and deployed according to local laws. | | 2. To understand that documents stored in a Microsoft owned data centre in Dublin must be subject to the laws or Ireland, EU and USA. | | 3. To note that after the UK leave the EU, then UK laws will not cover any documents stored in Dublin. | | 4. To note that USA laws can impose court orders on Microsoft to cause documents to be disclosed to USA courts - most countries share similar disclosure laws. | | 5. To understand that UK General Data Protection Regulations (GSPR) dictate that sprecial concent and agreements are mandated when personal data passes over a national boundary such as UK to EU. | | 6. To observe that at the current time, standard agreement terms have been drafted but not verified by a court so data transfer between countries may be subject to the Brexit deal. | | 7. To guess that after Brexit, a data breach from Dublin would not be reportable to the UK Information Commissioners Office - a data breach procedure must be documented. | | 8. To plan how to avoid email terrorist watch lists and criminal money laundering with money being sent overseas - to be aware of sensitive territories. |
| Document Control: | | 1. Document Title: Document Naming Convention. | | 2. Reference: 163117. | | 3. Description: Document Naming Convention. | | 4. Keywords: Document Naming Convention. | | 5. Privacy: Public education service as a benefit to humanity. | | 6. Issued: 15 Sep 2019. | | 7. Edition: 2.4. |
|
|