Sharepoint Pros?
-
I've got a client who is in the construction business. They are growing quick, have zero IT backbone, and dont want to jump into a construction management software package until we do some trials, testing, etc. In the mean time I thought they could benefit from Sharepoint for document management. Currently they are using dropbox......
I'm migrating them to O365 today, and their plan includes sharepoint. I've never really used it before, anybody want to school me on the basics?
-
What would you like to know? The biggest components of it are the base wiki platform and a very powerful document repository system. But Sharepoint is so much more, it is an application development platform powered by MS SQL Server. So you can make a list, for example, in SP that is actually a table in SQL Server that you can use as relational data throughout the site. It's very powerful once you start thinking about how data can drive it.
-
Do you want more than just file sharing features?
Sharepoint can do a lot, but it does have a learning curve to setup.
-
@JaredBusch said:
Sharepoint can do a lot, but it does have a learning curve to setup.
Both as an admin AND as someone managing it inside the application. If using a hosted setup, though, only the latter applies. And some features, like making it a document repo is easy. But getting the full power out of it is really hard.
-
Document management would be job one.
-
@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.
