Interface Support Operations – Before and After Go-live

Organizations struggle with properly resourcing a support team and understanding what is required once their interfaces go live. This article will give recommendations on how to estimate and track the support needs.

Understanding support requirements starts during the testing phase. Supporting an interface is not just about the number of resources needed to support an interface, but also the skillsets required to resolve each type of interface error. Ask the vendor for a complete list of errors prior to testing the interface and include them in your test plan. A comprehensive test plan includes scenarios that you expect to fail and gives your organization the opportunity to document the process to resolve the issues, the effort required and the skillsets required. This will provide the foundation for understanding the resources need and their skillset. The next step will be to estimate the number of full time employees {FTEs} required to supporting the interface.

Finding out at go live that the interface generates more errors that can be resolved effectively will be perceived as a failed project. My recommendation is to start with a phased interface rollout approach to limit the number of total messages that are processed each day. This approach has two benefits: the organization will be able to verify operational policies are in place for each type of error and give the organization the ability to estimate the FTE requirement to support the interface. The assumption here is that it will take a few days to a few weeks to stabilize a new interface. Once the interfaces have been stabilized, we can then calculate and define the FTE requirements to support the interfaces. For example, your phased rollout includes 5 out of 100 providers (1/20th of your total population) and it takes a total of 1 hour per day to support the interface you can estimate a .5 FTE once all the providers are live (1 hour/day X 20 = 20 hours per week). One caveat is that in order to truly have enough support coverage you need to ensure that there are 3 resources that can perform the same job function. Generally, you have the primary resource that is responsible for day to day operations. A back up that steps in when the primary is out of office and then a tertiary back that could be an analyst cross trained in case both the primary and back up are out of the office, or a resource is lost unexpectedly for any reason.

Now that you have properly staffed your interface support team, you will want to ensure there is insight as to how they are handling the errors. As managers, we generally are not familiar with all the integration tools, interface diagrams and generated reports to gauge how support is handling the error messages. My recommendation would be to first ask the vendor if they have a query to pull out all the error messages for each interface. At a minimum, you will want to track each interface, the type of error and the day the error occurred. Not only will this allow you to gauge the amount of errors but also identify if your team is able to handle the volume of errors. One other benefit of a dashboard is the ability to quickly realize a major increase in errors on a day to day basis. A spike in errors is generally related to an unexpected change (outside of your change control process) that should trigger a root cause analysis and feedback mechanism to the application lead in this area.

What I would consider the most important part of operationalizing support is the process by which updates to interface mappings or logic are tracked, tested, moved to live environment and transferred into support. Your organization's change control process must include interface changes that will impact your applications. There are many third party applications, such as share point that can be used to track the changes. At the very least, an excel spreadsheet on a shared drive can be used to document the changes. Documentation is critical to keeping track of changes, who made the changes, why the changes were made, and when the changes were approved for production. Generally, most organizations will create a change control team that meets on a regular basis to review all changes that are ready to be moved into production. This team should consist not only of the technical resources that made the change, but also a physician champion and a representative from each of the integration teams (patient management team, ancillary system team, and master patient identifier team) to ensure recommended changes are discussed across all integration points, not just the area directly impacted by the update.

#ChangeManagement #Interfacedashboard #interfacechangecontrol #interfacesupportoptions

Featured Posts
Recent Posts
Archive
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2016 Project Navigation LLC. all rights reserved