Hi, and welcome to this two-part series on building End User Business Solutions with Office 365. We’ll begin with what we have and how we get started. Then, we will focus on how we build, extend, and, ultimately, maintain the solution. By the end of this two-part series, you’ll learn how to avoid common pitfalls while building a great solution. However, we won’t get into some of the newer solutions that Microsoft has recently released, like Microsoft 365, Connections, or Listings…I’ll leave those for later blog articles.
So, I know what you are thinking; the user wants me to create what? I need to update my databases and servers, check to ensure my user counts are right, conduct an audit, handle seven support requests, finalize my budget for next year…you get the idea. Your regular job tasks takes up a lot of your time, and you need to figure out how to implement the right solution for the user/customer. So, what do we use? Well, let’s first understand a simple principle: Lean Six Sigma (L6Σ).
L6Σ is designed to achieve the fastest rate of improvement in customer satisfaction, cost, quality, process speed, and invested capital. Yes, I get it (*Snore*), but it really is a great principle to follow. How so, you ask? It does so by saying simply, build 20% of what you need and use 80% of what exists. But, if we apply this, won’t the cost be too expensive? In the past, yes, you could not do it for a cheap price; however, with the per-user price ability of cloud services today, we can do it for a cheaper cost than if you built it yourself. In the end, the goal is to build something with the thought of how else will this be used and by whom and how can it be used for another purpose, which will save you time and stress in the long run.
So, use 80%; but, 80% of what? Well, without doing marketing for them, let’s consider Office 365. If you talk to any sales rep or go to any Microsoft convention, Office 365 does everything and can even be connected to your toaster to tell you when the toast is done. That last part is possible, but I digress.
Now, you probably know that Office 365 can handle email, chat, collaboration, document management, and lots of other stuff. However, usually when a user comes to you and says they are looking to do “X”, it’s not going to be an email or chat sort of solution. Given this, our focus is going to be on all the other features that you can use from office 365 to solve end user business problems.
Next let’s talk about data storage. You have a lot of technology at your fingertips; but, in this case, let’s focus on SharePoint Online, Microsoft Teams, SQL, and Microsoft Dynamics/Project Online. SharePoint is a great system for storing data, limits aside. With SharePoint, we can store textual data, as well as binary objects like documents and images. It also provides built-in security for these data points, which is a benefit over the alternative, SQL. While we have no limits with SQL, everything that we get from SharePoint Online we must build ourselves. This includes permissions, including roles and users, tables, views, backup/restore, version control, and auditing. In the case of SharePoint Online, we are given these options out of the box.
What about Microsoft Teams? Microsoft Teams was built with SharePoint in mind. Before Microsoft called SharePoint the collaboration platform, but now Microsoft Teams is the place to go when you need collaboration for your team. So, what can you store in a Team that you can’t in SharePoint? Well the answer is nothing, but what’s missing is version control and some lesser hard limits on the number of team members. Retention is less Teams than with SharePoint, and you have two types of a team and data exposure, either public or private.
Finally, what about Microsoft Dynamics and Project Online? These two services are built on, you guessed it, SharePoint. Yes, for you technophiles out there, there is a smattering of SQL on the backend, but the user functionality is rendered on top of SharePoint. As such, the benefit you get is a predefined set of functionalities built on a common platform that you can extend or change to enhance the functionality your users are looking for.
So, have I answered what should you use? No, we aren’t there yet, but hopefully you now understand how you can get started. In the end, just figuring out where your data is going to be stored can be the biggest question you may have. If you make the wrong decision at the onset, the time it takes you to migrate to another solution can be a huge expense. Now, there are some things that I haven’t mentioned, like user limits, data limits, roles, service limits, and retention policies, but all these and more will be addressed in future blogs. For now, focus on what the user is looking to do, the security they need, and what information they want to store. This will get you started with the right service, and on the right track.
To get a notification when part two of this guide is published, subscribe to the blog.