alphaspirit - Fotolia
It may seem obvious, but it's important that channel partners document their processes to avoid reinventing the wheel and to ensure business efficiency.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
If a managed services provider (MSP) has a process that is going to be repeated as its business grows, the company needs to be able to reproduce it so that it remains consistent. In order to do that, the process must be documented, said Peter Kujawa, president of Locknet Managed IT, a division of EO Johnson Business Technologies, based in Onalaska, Wis.
"Effective documentation of your business allows you to look for opportunities to improve that process as you grow and move forward because you learn a lot about what works and what doesn't," Kujawa said. Otherwise, you risk flying "by the seat of your pants every time," especially if it is a process an employee doesn't perform again for another six months, he added.
Additionally, by documenting processes, MSPs can better train employees and ensure processes are followed. "It's a sign of operational maturity as an organization," Kujawa added.
Weaver likened process documentation to passing down a grandmother's recipe for apple pie; either you physically teach someone how to make the pie or you write down the recipe for them. If the MSP doesn't have that recipe written down, the information can become unreliable.
"If I say, 'Please bake me your apple pie' … but I say, 'I need 100 pies and I need five [employees] doing this,' what's the expectation each pie will be consistent? This is where documentation must exist. Otherwise, grandmother can't scale."
MSP documentation is all about increasing efficiency, agreed A. Alex Cabral, president and CEO of SI Portal, a provider of IT documentation software based in Lakeland, Fla. "Increasing efficiency increases productivity, which equates to the business doing better."
But it's not always that black and white for MSPs, Weaver added. "We come from an industry of break/fix, where no one wrote anything down. Technical people lived in their own world and wanted to hold the keys to the kingdom, and one way [of doing that] was keeping things wrapped in their head." Documenting a process, however, is part of making an organization redundant and resilient, "and it's a part of the basic best practices today of being a good service provider," he said.
The good news is it's now easier to document processes. "Today, compared to 20 years ago, we're in a much better position, and technicians are much more accepting of the idea that they have to document processes, policies and procedures."
The first step, Weaver emphasized, is recognizing MSP documentation is an important thing to do.
MSP documentation: Start small and build from there
Locknet has implemented an internal process to document client information as soon as the company onboards a new client. "It's very important that, as early as possible into the sale engagement ... [you document] whatever information you have about the client … in a place that's secure [so that] employees know where to find that information,'' Kujawa said.
Charles WeaverCEO, MSPAlliance
This enables Locknet to provide effective support to all of its client. "The challenge with any new client is they're going to expect support right after starting with you, and if you don't effectively document their environment, there's a learning curve, and employees will be flying blind," Kujawa said. "The client won't feel you've done your homework."
Weaver said "the majority of technical people in our industry" want to capture their processes, but are challenged by how to start documenting and codifying their policies and procedures. Some are daunted by the prospect that they may have to write what amounts to a manual. "The best advice I've seen is to start small with repetitive tasks you do every day and write them down." Tasks could include how the company approves and documents a change request or how it closes out a change request ticket.
The MSP can then gradually build from there, Weaver said. "You can't start out writing an anthology," he noted, recommending the approach of tackling "small, bite-sized pieces" instead. Otherwise, the person doing the documentation will get overwhelmed and never get started.
The company then needs to build upon those pieces and create secure, IT process-related procedures, Weaver said. "When they start doing that, they'll begin to realize, 'Wow, I need to go back and implement this.'"
There are other benefits of MSP documentation, as well. "One of the byproducts MSPs don't see is they can scale very, very quickly once they have documentation in place,'' Weaver said, "because they can train people quicker and hold existing employees accountable with a documentation policy versus without."
Using MSP documentation tools
Some MSPs opt to use a software platform. Cabral said SI Portal was created "because we were tired of looking for information. We hated going on vacation and getting called. We cringed when a peer left the company and tripled our work because they either had no documentation or it was hard to search through." The SI Portal software was developed by DSM, a provider of data center, professional and managed services, to help with its documentation needs.
Cabral believes that IT people generally waste a lot of time looking for information, which can be frustrating, especially when they are working on a deadline or when an emergency arises. "In the MSP and professional services world, it is even worse, as you have engineers that may work on dozens of customers. When a customer has an issue, an engineer may not know enough about the environment to resolve it on their own."
Ideally, he added, an MSP's processes should reduce ambiguity by establishing standards of operation. Because there are countless ways to tackle a task, documenting those processes and having documentation software that allows an MSP to designate where those processes apply can make life easier for IT, Cabral said.
Additionally, since IT people typically keep their documentation in their personal workspace, using tools like Password Safe or OneNote, when they leave the organization, all of their documentation and their passwords go with them, Cabral said. Some IT departments have a structured folder on a local or cloud file system, or they keep passwords stored in Excel spreadsheets. "Usually, this system fails because it lacks key features that a documentation system should provide," Cabral said.
Other ineffective approaches MSPs take when it comes to documentation, according to Cabral, include the following:
- A lack of guidance on what gets documented.
- The end user usually determines the structure, creating ambiguity as to how to find information.
- A lack of security, so there is no accountability for the access to the documentation and passwords.
- Some systems are not easily accessible when engineers are out and about.
- Some systems don't show how documentation is related to infrastructure and application systems.
What information to keep and how to capture it
The types of documentation to keep will vary somewhat depending on the business the MSP is in, Weaver said. That said, MSPs "should all start with some fundamentals, such as how they're going to handle internal redundancy and resiliency, a customer's physical and logical security, like password management, and the use of shared admin credentials on the customer server."
MSPs need to keep everything from contact and user information to information about a customer's network and systems and specific apps and passwords, Kujawa said. "Ideally, you even have information about some of the nuances of each customer, such as … somebody in the client organization [who is] difficult to deal with, and [if] there [is] a better way to deal with them on certain issues." Other types of information to keep include whether you have customers who don't want to be alerted by phone outside of business hours and, of course, contract details.
Locknet makes it a practice to do "a lot of discovery" before bringing on a new managed services customer, Kujawa said. This includes having a sales person meet with the client, a sales engineer run an assessment on the client's environment, as well as potentially bringing other engineers on site to provide other IT-related project quotes for that client. Locknet's project manager will then speak with each of those staff members and "extract that information quickly and put it in a database." As a result, "no information is lost," he said.
"A good MSP will know a lot about that client before signing the contract."
Get tips for transitioning your business model
Learn about MSPs building out their security practices