OR READ THE FULL ARTICLE BELOW
The Support Model Workshop also facilitates the discovery of stakeholder priorities and alignment of their views.
In this article, we describe the support model design workshop and what steps to take to ensure you build a robust support model for your application.
If you are not sure what the application support needs for your application are, we recommend organizing a support model design workshop to create or update the support model.
A support model design workshop is where all relevant stakeholders come together with support to compile an agreed upon model for supporting an application.
So, how does one organize such a workshop?
Make sure you have a good understanding of the individuals and teams that will be involved in the day-to-day operations of the application service or will be impacted when there are issues with the service. We recommend representation of each stakeholder community be invited to the workshop because this will give you a holistic stakeholder view and facilitates the development of the natural support team.
There are two ways to compile this list.
- You can draw some examples from experience or
- Ask your stakeholders for typical cases they have experienced.
Use these scenarios to facilitate the conversation and to help answer and think about the “what if” & “how to” support scenarios that may be encountered during operations.
To get you started, here are a few suggested examples of scenarios –
- HowTo Questions: If I am a user to go to, how can we best service and help the user. Then you ask yourself, what is the first entry point, maybe self-help and then to the xyz team. Maybe you discover that this team should have application and process knowledge.
- Situation Management for a Business Critical Application.
- Security and access permissions: creating, deleting user, changing access rights. Two parts, Authorization (always business, should this user get access (often line manager) and provisioning (can be automated can also be that there are several systems where the account needs to be set-up and you different teams need to be involved (SSO, AD, vendor application etc.)
- Release management and end-to-end testing
- Report provisioning, data management and configuration changes.
This is the first step in the process of designing a support model. (Please note this is also the same process to follow for “updating” a support model). The goal of the workshop is to identify and agree on the required support functions and, where possible, identify the providers of the support function. After the support model design workshop, you should have two deliverables as outcomes: the logical and physical support models
After the stakeholders have been engaged and the scenarios have been agreed, the next step is to:
Here are tips to consider for conducting the workshop:
- Start to work through the models by answering the suggested questions.
- Identify which functions are needed
- Who is best positioned to provide the support
- How will the support operate?
When facilitating this discussion, it is helpful to go through each scenario from the beginning to the end, working through the logical flow of the support model. Identify what functions are needed to facilitate the flow. In some cases, there will be a particular set of skills or expertise needed to provide these functions. In these cases, we can look to our preferred or designated providers for that function.
It is important to encourage the stakeholders to actively participate in the design activity. The workshop’s facilitator should help promote an active discussion between the stakeholders. It may be helpful to remember that there is not a “one size fits all” approach for supporting an application. Please remember, a valuable and natural benefit of the support model design process is the discovery of stakeholder priorities and alignment of their views.
To ensure the stakeholders’ priorities are aligned in the outcome of the support model, keep these ground rules in mind:
- Have an open mind when evaluating all options and scenarios
- There is not a ‘correct’ process for any one scenario to flow through the model
- Keep the dialog open and productive when discussing alternatives
- Use the suggested scenarios as starting points if there is lack of clarity on the way forward
When you start to design an application support model, you need to figure out what kind of support you need. The easiest way generally is to run through several scenarios with your stakeholder representatives.
Start asking questions:
- What kind of functions do I need?
- Do I need a business service desk that helps whit how to questions
- Do I need a super user community that represents the user community in functional requirements?
- Security access analyst, that approves request for access, do I need technical teams for the provisioning of the access
- Do I need functional and/or technical support for databases, reporting, etc
- With some application we also do the development, so do I need development team for enhancements and changes. Do I need people with technical knowledge for bug fixes
By going through those scenarios, you start identifying those teams. You start identifying those functions you need to provide the end to end support for the application.
once you have that mapped out you can go to the second question, and often already a lot of the answers have been gathered by going through the scenario’s. and that is who is going to do it, who is going to provide this function, the providers.
*note: there can be multiple provider for a function for instance technical support can include os, database and network support from different providers)
Fulfillment can be either internally or external. E.g. if you have a SaaS providers they will probably provide the functional & infrastructure support and could also provide support for How to questions, but not per se. It is always situational.
What is a Support model?
A support model describes how support needs are being fulfilled. It describes
- the support roles and their expertise, known as functions and
- who is providing the service and under which conditions, or providers
Generally, it is a diagram that maps the various support stakeholders and process flow for incidents, enhancements, change requests, and many other support situations.
Within the Support Model, there are three main links. The Functional link, Application Link, and Infrastructure link. Each link identifies several possible functions needed to provide the support for a solution.
The Functional support link is also known as the business link. Here is where the first line of support typically lies. This is where users come with functional, how-to, master data management, enhancement and process ownership questions. Often the Functions identified in this area are provided by teams in the business itself, giving it the name of business, or functional support.
The Application support link. The functions in this area are typically provided by the IT Service Operations Management Organization. This is where the accountability for the solution’s security and reliability rests. They are responsible for operating the IT controls. Any bug fixes or changes should be done through the Functions in this support link.
The Infrastructure support link helps support all the IT infrastructure components used to provide the application service; like servers, storage, and network. Although infrastructure functions are highlighted in blue, you will find the people providing the support sit within the same team or with one of our vendors.
Figure 1 – Example Support Model
Sometimes it can be beneficial to develop the support model in two iterations. This approach can be beneficial when there is a lot of uncertainty or disagreement.
- 1st Iteration, the Logical Support Model describes the support functions and their (hierarchical) relations (often modelled with 1st, 2nd & 3rd tier lines of support)
- 2nd Iteration, The Physical Support model described how, by Who, when and where support will be provided (for the individual functions*.)
The selection of the functions is driven by the purpose of the application and its usage. It is beneficial to be aware of any changes to the delivery model. For example, if a solution’s support changes from in-house support to a SaaS or ASP based support, the needed support functions should remain the same. Remember that it is the purpose and usage of the service that drives the support needs and not the delivery model. However, the delivery model selected will have an impact on who provides the support for the given function.