4 Steps to Demonstrate Value on your PCPM Odyssey
avatar

In this last blog post of the PCPM series we are going to address several steps to ensure the success of your APM/NPM deployment in your patient care environment. 99.9% of these steps can be utilized by other business verticals as well.

Step 1 … What Problem Are You Trying to Solve?

Figuring out what problem you are trying to solve can be quite a confrontational question; however, it is the most critical question to answer. It is my personal belief that every enterprise, large and small, needs a degree of tools – both commercial and open source. However, to apply your budget, time, capital, and operational expense towards tools willy nilly” is a simple waste of resources. You must have a problem for which these tools will be utilized to solve. For example, if ‘X’ application goes down, your business suffers a loss of some kind, whether it is reputational or sales. Generically stating to your management, “I need packets” is not an appropriate problem statement in today’s businesses.

By defining the problem that your tool will solve, you start defining your requirements, which makes vendor selection that much easier.  Otherwise, you have a solution looking for a problem, and that’s NOT the problem solver way!

Way too often I see teams attempting to solve a problem of their own, which isn’t a true business problem worth investing to solve. Prior to engaging vendors, ensure your management/leadership is on board with reviewing a new tool set for the problem you have identified. Or better yet, review what your existing tools can do for you with your existing vendors.

Now that we know the problem that we are solving and have identified its impact on the business, it is now time to review vendors and their products.

Step 2 … Selecting the Problem Solving Team / Vendor

Anyone who has any experience with APM/NPM toolsets knows implementation doesn’t occur in a matter of days or several weeks. Thus the vendor, that you purchase your solution from should be looking at how their tool(s) fix your business problems of today and likely the problems of tomorrow. This idea is focused on the ability to demonstrate value to you and your business. But this process and the need to demonstrate value doesn’t stop after the completion of the purchase/sale; it continues for the life of the partnership. So start asking your vendors the tough questions; how often do you plan to be on-site or have remote sessions after we purchase your gear? How have you demonstrated value at other customers similar to mine?

Inside the tool space, I see two common deployment models, both of which are direct result of the local team’s approach: solutions and boxes. Solutions have a company and/or local team supporting the product(s) and how they demonstrate value. Boxes, on the other hand, were equipment which was sold and the “sales team” was never heard from again with no value never being demonstrated.

What type of product would you like to procure and invest? Remember we are enabling care givers, not deploying networks, code, wireless, etc. If your vendor doesn’t understand this concept, then they are a sales team, not a partner looking to solve your problem.

Step 3 … Design

Those who know me personally know I “geek out” about numbers, math, and pretty charts. I personally believe after we determine the problem, and select a vendor, the design is of the utmost importance.  The design should be based upon math to support the bill of materials and resulting in the solution being sized properly. This step helps ensure that you solve the actual problem discovered in step 1. If your vendor isn’t asking questions surrounding load or performing a generic sizing exercise, and suggesting a 1 size fits all model, RUN AWAY!

So let’s begin by first referencing the problem we located during step 1. Where does solution X need to be deployed to produce metrics around your particular patient care service? This may be a logical area of your network, or a physical location, or most likely is a combination of the two.

You will likely need to engage multiple members of your team to help with this step, and even then, you may come across hurdles. Often we see organizations, which through years of attrition or acquisition, lost tribal knowledge about how a particular application/services were architected. Don’t feel bad. Many people are in the same boat as you. Do your best and embrace a phased based approach so that you’re able to adapt as more information becomes available. Ask questions related to the scalability of the product should you need to expand. This is also an important time to set reasonable expectations within your own organization.

In the case of packet based solutions, this stage of the design will likely include discussions about the location of taps and spans. This can seem like a daunting task or cause heart burn, especially if you don’t know specific knowledge on how the actual application flows across the network. Again, think scalability and flexibility. Can we easily and reasonably add onto the solution as more information is uncovered?

As the design starts to take shape, don’t be afraid of asking the question, why did you place two pieces of equipment in the bill of materials and not just one? If you see a deer in the headlights look. … RUN!

Step 4 … Value

As the deployment of your freshly purchased solution starts, ensure you set appropriate goals for when the solution will be deployed. This step should be immediately followed by a series of smaller tactical goals for establishing some “low hanging fruit” type wins. A fantastic place to target for wins are the areas where the clients access the application. An example of this would be the web tier of a classic three-tiered application. After the short term goals are achieved, then move onto larger goals surrounding the original problem statement.

Your first few wins shouldn’t be targeted toward solving world hunger or curing cancer. Instead start small, work with your problem solvers to set reasonable dates necessary to demonstrate value and stick to those dates. Your vendor should assist you with these first few softballs, and provide a format and a vehicle by which to take these wins to your management.

Remember, this is only the beginning. As the weeks turn into months, reflect and set appropriate goals to produce “wins” every X months to further demonstrate value and remind those around you of why we purchased this tool.

Applying Advanced APM to Healthcare, Part 4
avatar

Throughout our Patient Care Performance Management (PCPM) series, we have reviewed individual performance management categories. When I consider the notion of “Advanced APM”, I see it as APM (based in traffic flow data) combined with a “service based” mentality. This leverages APM+ metrics … Continue reading

Applying APM to Healthcare; a PCPM Odyssey (Part 3)
avatar

In the first article in this series, we reviewed how NPM statistics will provide details of the operation and performance of internal network super highways. The second article introduced the role of service enablers and how their poor performance can drastically … Continue reading

Applying Advance NPM (aka NPM+) to Healthcare; a PCPM Odyssey (Part 2)
avatar

While traffic utilization and link error rates (NPM) have their place and uses, we must look deeper to truly impact patient care. Service enablers for example are services which are often overlooked and neglected, yet have the most widespread impact to … Continue reading

Applying NPM to Healthcare; a PCPM Odyssey (Part 1)
avatar

Network Performance Management’s (NPM) roots date back to the early 90s with emergence of SNMP, MIBII, and NetFlow. Quickly every IT shop, small and large, had various toolsets graphing all sorts of network metrics. Many of Network Managers lived and … Continue reading

A Patient Care Performance Management (PCPM) Odyssey
avatar

When I refer to Patient Care Performance Management (PCPM), I am referring to applying Application Performance Management (APM) and Network Performance Management (NPM) strategies in a healthcare environment. (While this is directly applicable to healthcare, these can also be applied to other … Continue reading

Need a Dr. when your EMR gets sick ??
avatar

Problem to Solve – My healthcare organization is deploying an Electronic Medical Records (EMR) solution as per federal regulation.   What can I do if there are performance issues with it? Ah, the Affordable Health Care Act.   What a fun, enjoyable … Continue reading