With every Cloud, Software-as-a-Service (SaaS) product implementation, you inevitably get to a point where you need to ask yourself the question: “How will we support this new system after it is built and deployed?”. This is as true in cloud procurement system implementations (Ariba, Coupa, Ivalua, etc) as it is for any other cloud solution you are implementing in your business (SuccessFactors, S4 Public Cloud, Hybris, etc). Hopefully, you are considering this while building your initial business case as it will most likely mean additional Full Time Equivalents (FTE) dedicated to supporting and administering the solution on an ongoing basis. Implementing a new system in your business is like bringing a new child into the family: It needs parents to take care of it and ensure it ages wisely! Too often do we think queries and improvements will take care of themselves “automagically” after we implement!
Of course, the number of FTE needed to support a cloud system should be lower than an on-premise system. That is a main part of the value proposition of cloud systems. However, this value proposition is mostly related to the technical administration of the solution:
- Updating and maintaining hardware
- Updating and maintaining operating systems
When it comes to the business & functional side of administration, these tasks remain even in cloud systems:
- Administer user creation and role assignment
- Review vendor release notes and decide how/if new solution enhancements should be used
- Continuously improve processes implemented at first
- Update approval workflows to match changing business realities
- Resolve any end user issues and queries
- Onboarding new vendors on your Business Network
Therefore, it is important to think about how these tasks will be carried out and who will execute them. Ideally, you integrate the support of a cloud solution into your existing IT Help Desk infrastructure with a few minor additions which are vendor specific. However, if you are starting from scratch, here is a good generic model from which to start from:
Everything starts with an End User who either wants to resolve a problem they are having or lodge a request for action in the system (ie. Update an approval flow). The goals are to:
- Get their problem or query resolved satisfactorily as fast as possible
- Protect your Functional Analysts so they can continue delivering on what is most likely project work
Therefore, we want to:
- Empower the user to be as independent as possible in problem resolution
- Automate repetitive requests as much as possible
- Triage the requests so that only truly difficult and critical requests end up on the desk of our functional analysts and that when they do, requirements are clear
This is where the Problem Resolution Funnel comes in. Each level described below attempts to serve the above statements:
Level 0 – Reference Documentation
This level represents work instruction documentation that should be made available to end users as part of the initial implementation project. Ideally, these are maintained in a central location (ie. online application such as EnableNow). As the user is trying to complete specific tasks in the system, he will be able to reference these documents to support the completion of his work. These documents should also be an integral part of end user training program to help them develop the reflexes of consulting this documentation before reaching out for any other kind of help.
Level 1 – Super Users (Ideally on-site, fellow End Users)
If the reference documentation is not sufficient for the user to complete the desired task, this end user should be able to refer to their on-site application super user (these should be identified and trained during the initial project). This super user should be a more advanced user (pick them consequently!) and should be able to answer most standard queries coming from his/her colleagues.
These first two levels of support aim to reduce the amount of support tickets created for training issues by resolving questions and queries before ticket creation even occurs.
Level 2 – Help Desk
If the end user and super user are not able to resolve the issue at hand, then an IT support request should be logged by the user in a common enterprise tool (usually the link for the tool should be kept on the company intranet). This ticket will be routed to a support agent who can resolve basic queries and requests related to the solution. This ticket should be treated in priority in accordance with your support Service Level Agreements (SLA).
Level 3 – Functional Analysts
If the help desk agent is not able to resolve the support ticket, they should document their findings and additional problem context and escalate the request for assistance from functional analysts. The ticket should only get to this level if the problem is very difficult to resolve and requires expert help. These resources are most likely on other projects at this time so you want to minimize the impact of production support on your project timelines. Also, depending on the size of your organization and amount of applications supported, Level 3 can be split into two levels if your initial help desk (level 2) is only a triage level. You might have “Generalist Functional Analysts” who have working knowledge of many areas of the solution but aren’t the final owners of the solution.
Level 4 – Vendor Service Request
This is the additional level when it comes to supporting SaaS solutions. As some of the technical maintenance functions are outsourced to the vendor (this varies by solution), there may be certain problems you are unable to resolve internally. After Functional Analyst evaluation, if the problem is deemed to stem from inaccessible configurations or system settings that only your vendor can change, this means a service request will need to be opened directly with the vendor and linked to your internal ticket (and ideally a different status). All vendors have different ways of working but most will provide you with a web interface to log your ticket. Generally, if the ticket has gotten to this level, it should be re-assigned to Level 2 for the follow-up with the vendor. They are able to interact with the vendor with regards to resolution coordination and come back to the End User when the situation is resolved. Finally, after resolution, the help desk agent documents the solution in the ticket and closes the ticket. It is also beneficial if he notifies the Functional Analyst for general knowledge building for similar problems in the future.
This approach works best if you route all request types through the same help desk (project requests, IT support requests, improvement requests, access requests) as it trains End Users on using a single tool to get IT help within the enterprise. Also, it makes reporting a whole lot simpler as you have a single source of truth. Of course, (and this is meta…) you also have to treat your help desk software as a system which needs continuous improvement and an administrator… It is hard to preach best practices to business customers if IT is itself a poorly shod shoemaker…
A few systems I’ve used (and liked) in the past to support this process are ServiceNow, BMC Remedy or SAP ITSM/ChaRM if you are a SAP Solution Manager user.
For more detailed information on Help Desk models, you can look up the Service Operation book in the ITIL Methodology. You can also feel free to reach out via my contact page.
———————————
What’s been your experience setting up post-implementation support in your organization? What challenges did you face? In your opinion, what are the differences between supporting on-premise and cloud solutions? Let me know in the comments.
If you liked this post, why not Subscribe
Last Updated on January 8, 2021 by Joël Collin-Demers
