Five Drivers for Internal versus External Software Support
Enterprise Software Systems are becoming like the telecom companies. Try giving any of the major telecom companies a call about a technical issue or billing question. You might as well record your question, because you will keep repeating it until you find someone that can correct it, then be prepared to call back when the issue still does not get resolved.
We are getting down to just a select few vendors that offer an Enterprise Solution for both inpatient and ambulatory systems. This of course within the large organizations with multiple hospitals or the academic medical center market. This just means that more clients are competing for support in an already crowded, resource lean vendor market.
Migrating to a new platform is daunting enough. But after the go-live party, the vendor installation team moves on to the new client and you are left with a phone number to call. “Congratulations, you have reached the support line, press #1 for someone that can listen to your issue, press #2 for a sympathetic patronizing response, and press #3 to be placed on hold until the person that can really fix your problem gets off the phone with the previous ten callers.”
CIOs recognize that they have to augment the vendor support with a day to day team. This internal support performs maintenance functions like dictionary or table updates, adding or removing users, and acts as the first support tier when the system does not operate how the user expects. Your internal support often has basic “super user” knowledge and depending on the vendor and your contract, you may be able to actually troubleshoot software issues internally.
Here is the rub: If you pay an ungodly amount in support fees to your vendor, why should you have all these FTE’s sitting around waiting for the system to break? At least that’s how the “C” suite looks at it. New software systems always start with an expected ROI, and sometimes this includes downsizing the current information technology department. After all, this new Enterprise Software will replace all the other systems, so you will not need all these different support skill sets; right? At least that was the plan. Talk to anyone that has gone through the post installation of software and you will hear that buyer’s remorse of getting rid of all those resources and cubicle space. Caveat Emptor. Because now all the user support calls and response time for productivity issues are bubbling up to the board room, and the CIO is wearing the target. Never mind the ROI now, tell me how I can keep all these complaints out of my email?! Five things to think about:
- Help Desk Management. This is really just one piece of the puzzle. You want the right resources on the phone that understands the workflow, but also understands the software shortcuts. They can help with the bulk of the issues, but often have to document an issue for further support.
- Basic maintenance and customization. New screens and customization is that double edge sword that all software development struggles with. Make it easier on the user, but don’t introduce code that will break some other feature/function and don’t customize it so far away from the other clients that you can’t push out software patches. You should have resources to help with these issues. But you also need help with patch management, and management of your development server to make sure everything is thoroughly tested before code gets migrated to live. At the end of the day, if the users are not getting the same or better response that they had before the new system, then the perception is that this “new” system is worse, and the IT department just can’t keep up with all the issues. The other part of this is documentation. What does the patch do to functionality? Have the trainers been notified? Will the trainers have time to develop new training on the changes and screen designs? Does it break other functionality?
- Major upgrades. These are often woven into your contract. Ignore a few upgrades because you have better things to do, and you fall out of support. So you really don’t have a choice. The vendor wants to make sure their support team is dealing with the same issues and “scripts” for handling typical issues with a particular version, and of course they want you to benefit from all the feature/functions improvements. However, upgrades use up a large amount of resources, and demands a methodical approach. Hopefully what you get from the vendor is a decent project plan and many vendor resources similar to your original install. If not, you either reach out for temporary upgrade resources or set aside all you other items on the “To-Do” list.
- Integration. Regardless of the sales pitch, you will still have interfaces to other systems. In fact you might have interfaces to applications branded by the same vendor. You need to have internal expertise with HL7 and interface engines. Keep in mind that with Population Health and Analytics you will either be feeding information externally or developing your various data marts to help with managing your patient population. It’s no longer just about the billing, it’s about deriving helpful clinical data to clinicians in order to provide clinical excellence.
- Service Level Agreement. How do you know how many FTE’s to provide for support? A Service Level Agreement (SLA) clause can be woven into your contract to make sure the vendor is able to meet your bench mark. This is only as good as the penalties imposed. It is not enough for the vendor to promise “in good faith” that they will respond to an issue within a certain timeframe. No teeth in your SLA means you need more internal support. The more they are accountable the less FTE’s you have to provide. The balance is in the Software maintenance and support costs versus internal FTE budget.
Eliminating FTE’s because you will no longer need niche’ system support makes sense...But you better keep that cube space for new support resources, or be prepared to call and press #1 for someone that can listen to your issue, press #2 for….