Support Model - Specific to roles

In a multi - functional or multi departmental enterprise, ongoing services and supports determine the foundation of business success. More and more medium to large sized companies have developed their internal self - support systems. For example, the ICT Help Desk.

The basic business process for a self - support system usually starts with a technical issue. It looks like this: If a user encounters a technical issue, he/she firstly gives the Helpdesk a call or lodge a ticket in the system to describe the issue. Then a helpdesk officer will help user identify the issue, define its class, type and responsible team. Afterwards, this message will be updated and past onto its relevant team or personnel. Once the message is received, its relevant team or personnel will investigate the issue further with user and therefore technically resolve the issue. The final step for this process, is to confirm its completion and close its ticket.

Oftentimes it is pretty clear of where the ticket should go if the faulty application or server is supported by a particular team. Another popular way is that an area or a department is always looked after by a particular team. However, sometimes the technical teams have to get permission from an authorised personnel before  they can go head and fix the issue. e.g. put someone into a departmental server, create someone an access to a online project site. In this case, the authorised personnel also becomes very important in the self- support process, even though they usually do not work in a support team.

In most cases, the heads of departments communicate with each other on a fairly high level. The detailed structural change is barely communicated to the base level employers outside the department itself. This causes confusion when it comes to the system support as the original authorised personnel could be moved into another irrelevant position.

For example, today the technical team has to ask Mr Smith's permission before they set someone up in the company's network. Tomorrow,  Mr Smith moves to another position which looks after the electricity, therefore he is no longer the right person to give network permissions. Maybe Mr Smith can tell the technical team who is his replacement for the network but imagine if he has to explain it to every single request until the document is changed? I think you understand in a complex enterprise, changing a document is not lighting fast. People usually worry too much and the formal process takes time.

So, why do we need to update the document then? Though Mr Smith moves to another team, his previous role doesn't move. Frankly speaking, the authority in general is associated with the role but not a specific person.  For instance, the Head of Reserve Bank Australia has the authority to direct the national cash rate, doesn't matter who is on the position.

In conclusion my suggestion is, instead of writing down a person's name in the document, write down the role that is responsible or authorised to give the permission. In this way, delay for the support and services will be minimized, confusion and unnecessary change request will be avoided. As support and service is one of the key fundamentals for business success, improve its efficiency will also improve your chance to achieve a winning business.