Sharepoint Pros?
-
@hubtechagain said:
Document management would be job one.
That's super easy then. It's all built in and ready to go as soon as you log in.
-
The really big thing moving to documents on SharePoint is to resist the urge to start making folders. Just don't do it. Yes they exist, many people demand them, but using them (with only rare exceptions for special cases) is a mistake and not how SharePoint is designed to work. This is a database driven system, not a file system driven one. Don't try to mimic old file system methodologies, think of it as a database. You can add all kinds of powerful metadata to the files including both ad hoc data and highly structured data being driven by SQL Server Lists that you make in SharePoint. This lets you organize and find files in powerful ways that filesystems can't do.
-
So when moving from a current folder file structure to share point, how should one behave?
-
@hubtechagain said:
So when moving from a current folder file structure to share point, how should one behave?
Ideally, to really leverage SharePoint, you move all of the files over to a flat document repository without the folder structure. But you have to plan ahead and add metadata to the files as you do so or you will lose the information about them that exists in the folder structure. There are a lot of different ways to approach this, one is to use "tags" in the metadata to tell you what the folders would have been, but taking the time to add more data than you had before is very useful.
-
I need to do this to. What's the easiest way of adding metadata? I'd simply want to tag each file with the name of the directory it was copied from. Initially I have about 10,000 files in around 700 directories.
-
@Carnival-Boy said:
I need to do this to. What's the easiest way of adding metadata? I'd simply want to tag each file with the name of the directory it was copied from. Initially I have about 10,000 files in around 700 directories.
With 10K files, easiest way is to hire an old fashioned data entry clerk to do it for you
-
I was hoping for a slightly more hi-tech answer! -
There must be some level of manual work involved, but i would suggest you check Sharegate, its a very good tool that can do most of the heavy lifting, gives you an option to add Meta Data to an excel sheet during the migration process, you can add meta data and migrate.
http://en.share-gate.com/migrate-file-shares-to-sharepointCheck Sharegate blog topics as well, as they are well written and covers most topics on Sharepoint whether its Online/on premise. One good page is http://en.share-gate.com/blog?category=sharepoint-migration
Good luck. -
@Carnival-Boy said:
I was hoping for a slightly more hi-tech answer!It's a tough one because the data is presumed to not exist yet. In theory you can pull some data from file names, folder locations, permissions or something and then make a script to interpret that. But many companies would not have that data even in those ways. It's a tough one as the new system has so much more power than the old, but to leverage it data that didn't exist before has to be added to get the huge leap forward.
-
-
A quick Google suggests FCI is the way forward, but I need to look into it more.
-
I would be interested to know the results. Just to avoid confusion, as it happened to me, FCI is File Classification Infrastructure. Got a guide on doing this, but not sure how meta data is handled on this.
-
when you say add metadata to files, what are you talkign about?
-
@hubtechagain said:
when you say add metadata to files, what are you talkign about?
At the highest level: "Data about your files."
At a practical level it is like "tagging" your files. It is based on lists in Sharepoint. So you have some lists built in, such as the "owner and the editor" of files since the users list is part of Sharepoint. You could add a list of departments, topics, regions, offices, events, customers or similar to use to add data about a file. Pretty much anything you care to track.
-
So I will give a practical example. NTG uses Sharepoint. NTG is an MSP and has customers. NTG's Sharepoint site has a "list" of our customers that is stored in SQL Server via Sharepoint. In the customer document repository we made it mandatory for someone saving a file there to record the associated customer to which a file is referencing when saving the document. Basic metadata like the author of the file and the date in was created are always there, just like on a normal filesystem.
Because every file in this document repo must have a customer associated with it, anyone looking for data on that customer "ABC Corp" can just do a filter on that customer and only that customer's files are displayed. It's better than folders because it is flexible and not tied to a single detail. Sure we could do this for one item, one time using a folder structure.
But what if we want a second piece of metadata associated with the file? What if we wanted to only see Word Docs or OneNote files? What if we we had metadata telling us that a file is about customer configuration data or their SLA guidelines or billing history or documents related to taxes? With metadata we could choose to filter on any one or any number of these in ways that folder structures cannot and make it faster and easier to navigate large amounts of files.
-
Is metadata the same as Sharepoint columns? So, for example, I've created a new document library to store vendor invoices. I've added a column to that library called "Vendor".
-
@Carnival-Boy said:
Is metadata the same as Sharepoint columns? So, for example, I've created a new document library to store vendor invoices. I've added a column to that library called "Vendor".
Metadata is stored in lists which are database tables which are made of columns, but I wouldn't call them the "same" as the database stores a lot of stuff, only some is used as metadata and used as that only some of the time. But if you have a library called Vendor and you have a list of vendors stored in a list in the database and you are applying that list as a reference to a file, when used there it is metadata.
-
This is a fundamental change to the creation of documentation.
Like posting here on SW (or most forums these days) we can add tags. It's something I rarely do, and instead Scott follows me around like a kid with a cold and his parent wiping his nose.
The need to add this additional information is obviously very helpful when you're searching, assuming you've added the correct tags/metadata, but now you've also added more time that it takes to create/save that document.
I was trying to understand why my physicians (and medical staff) hated EHRs - it's because it truly required about 2-4 times the amount of documentation than paper charts did. There were two reasons for this. 1) things that we should be been recording were just being skipped - OK this is a win for EHR even though the non recorded data clearly didn't hurt us enough in the past to make us change to ensure we recorded it, 2) EHR added many new required pieces of documentation we didn't worry about/need in the past.
We went from having 1 Provider to 1 medical assistant, to needing 2 medical assistants per provider while in clinic. So now not only are we paying for the software (and infrastructure) we're paying for a lot more employees.Which ties back into Scott's comment
@scottalanmiller said:With 10K files, easiest way is to hire an old fashioned data entry clerk to do it for you
-
@Dashrender said:
This is a fundamental change to the creation of documentation.
One of the important SP features is that you can make some of the metadata mandatory rather than optional. The user can't save the file until they fill in the metadata.
-
Now don't get me wrong - I love the idea of moving away from the old folder structure, I still loose things in there.
Google is taking the same approach with photos. The idea is a single 'folder' of everything. Then they add the metadata for you (who's faces are in each picture, where was it taken, when, etc) then you search for what you're looking for.
