When your IT systems are unexpectedly interrupted, how and why the incident occurred doesn’t matter.
At least not in the moment.
The only thing that matters during an abrupt downtime is getting your business up and running again as quickly as possible.
This is why every business should have an IT incident management plan in place.
An effective incident management plan includes creating and following landscape diagrams, support models, action plans, and routinely auditing your information for accuracy.
In this article, you’ll learn more about each of these support documentation components and how they should work together to create a seamless process flow to maintain accurate information and deliver a quick fix when something breaks.
Landscape diagram sets the foundation
The landscape diagram is a highly detailed map of your company’s network topology that clearly illustrates which systems relate to the traffic flows of the services.
This diagram serves as the foundation of your IT support process.
Whether or not you’re in an enterprise environment, the number of components from end to end can be very complex. The level of detail you include is critical to helping your support team identify exactly where things can go wrong regardless of the complexity of the landscape.
The landscape diagram should include:
- Every vendor
- All critical devices, such as servers, switches, routers, etc.
- Source and destination IP addresses or URLs
- Traffic flows with labels
- Data center labels
In addition to providing your support team with the minimum data set it needs to raise an incident, the landscape diagram is the starting point for all documentation that follows.
It’s always better to show rather than tell when designing a landscape diagram, so let’s take a look at a good example and a not-so-good example.
Good Landscape Diagram
This good example is an adaptation of a landscape diagram that Odyssey Information Services designed for a large multisite client and only shows a small portion of the full landscape diagram.
What’s important to note in this example is the level of details, including router names and traffic flow. The specific vendor names have been omitted from this example, but the original diagram includes them in order to provide clarity to the user.
The lines in this diagram are also clean and color-coded to make it easy to identify who is connected to whom.
Not-So-Good Landscape Diagram
This is an example of a not-so-good landscape diagram. You’ll notice how we can see the vendors and traffic flow, but there are no device names. The lines are also all over the place, which makes it difficult to follow.
Both good and not-so-good diagrams illustrate the same service for connecting Vendor A to Vendor B.
However, the difference between the two is that the good diagram shows HOW the vendors are connected through the routers and firewalls. The not-so-good diagram does not.
That bit of detailed information is key to providing your support team with the minimum data set required to submit the initial service ticket.
Support models tell you who to contact
After you’ve used the landscape diagram to determine where the break occurred, you can pull in the support model to figure out which support teams need to get involved and how they talk to each other.
Each technical environment requires its own support model because the details are different, such as vendors, telecoms, infrastructure, hours of support needed, etc. If you try to cut corners by copying and pasting information from one model to the next, you will have incorrect information that will ultimately delay your response time.
Pro Tip: Don’t cut corners when creating your support models. Put in the time at the beginning to save time in the end when it matters most to your customers and revenue.
Now let’s look at a good and bad example.
Good Support Model
In this good example, you can see how the arrows are coordinated by colors to help identify different team connections. In addition, solid lines are used to represent incidents while dotted lines represent escalations. The use of colors and line styles makes this model easy to follow and to understand who talks to whom.
Not-So-Good Support Model
While it’s easy to see which teams are involved in support, it’s challenging to follow the arrows to see which teams support each other.
Also, unlike the good model, this model uses the same line to represent incidents and escalations.
How are you supposed to determine which is which? The answer is you can’t.
Put the landscape diagram and support model into action
After your landscape diagram and support models have been thoroughly detailed and checked for accuracy, it’s time to put them into action by creating action plans.
Action plans combine details from the landscape diagram and support model, along with examples of common problems (scenarios), to form the initial service ticket.
Here’s an example of an action plan that we use for one of our clients at Odyssey Information Services.
In this example, you can see what the issue is that needs to be resolved, what information needs to be included (from landscape diagram) and who needs to be contacted (from support model).
Some vendors, for example, will not accept a service ticket without router/IP addresses. Therefore, it’s important to include that information in the landscape diagram.
If you do not know who to contact and if you do not know what information you need to provide, you cannot report the issue—or at least you can’t do it accurately or timely.
Accurate, detailed information is key!
Audit your contact information regularly to ensure accuracy
Documentation is everyone’s least favorite part. I get it. But it’s also the most important.
Ok, I know I said that about every step, but this really is the MOST, MOST important part.
People leave their jobs all the time.
They quit. They get fired. They retire. They even pass away.
Maybe they changed roles within the company. Maybe they lost or gained responsibilities.
All these changes are important to document so your support team doesn’t waste time contacting the wrong person.
The wrong contact information could dramatically slow down your response time from a quick 30-second fix to an hours-long headache as you track down the right person.
At Odyssey Information Services, we audit our clients’ support documentation twice a year. We’ve figured out that works well for us due to the large amount of vendors we have to keep up with. We catch changes every time we audit.
Twice a year may not be realistic for your company, but you should commit to auditing your information at least once a year to ensure your contacts are up to date.
Your customers, support teams, and your bottom line will all be happy you did.
Don’t overlook incident management
I hope this blog article has helped you see the value of support documentation and how you can successfully implement an incident management plan for your organization. Creating your support documentation with all the correct information is a process that will take some time.
Odyssey Information Services has dedicated subject matter experts who know all the ins and outs of creating and maintaining support documentation for organizations of all sizes and industries.
Reach out to us if you need assistance with creating and/or maintaining your company’s incident management documentation.
About the Author
