Be Prepared

12-1-17-Prepared-Cube-Down.pdf (1 download )
Be Prepared
This week’s tech support bulletin will discuss preparing for a worst-case scenario.  You’ve got a Cube that has gone down and requires repairs…. on a holiday weekend.  That means you might not be able to get a replacement Cube out for 3 or 4 days, which should never be considered acceptable.  There are several steps that can be taken to mitigate the difficulties and frustrations that can arise from a Cube that is down.
1)     Know your facility’s IT department staff and any limitations that may exist.  Setting up expectations for their responsibilities, your responsibilities, and RCare’s responsibilities can limit the time it takes to correct the issue.  In some cases (plural), a facility’s IT department isn’t even aware of the system until they take the Cube down by changing over IP network configuration.  These changes should be planned and scheduled.  It is upon the responsibility of the distributor and the facility to maintain this relationship and to prepare for any network changes.  RCare cannot troubleshoot end user network issues.
2)     You should have a spare Cube ready to go out at a moment’s notice.  It will take a minimum of 24 hours for RCare to build and test a replacement server.  If troubleshooting is done after hours, or on a weekend, that time will only be extended.
3)     A spare Cube is great, but without a backup configuration file the down time will be extensive.  Teach end users how to save backup data.  This is crucial, perhaps the most important thing to teach them before the system goes live.  Even if you have a backup server ready to go, if you don’t have the configuration file you will have to relearn everything from scratch.  So instead of it taking RCare several hours to download the file, it could take you several days depending on how large the facility is.
Step 1:  Select “Backup” option under the system settings tab
Step 2:  Select “Backup Configuration” and “Backup Incidents”
Step 3:  Download Backups
The logistics of purchasing, shipping, installing, and testing a RCare nurse call system typically takes months of preparation and execution.  In the rare case of when a server disrupts that careful planning unexpectedly, there are one of two ways to solve these potential situations.  The first is to be prepared, in which case there is understanding across the board regarding the “what if?” process.  This involves less frustration as well as minimal downtime.  The second involves trying to replicate months’ worth of work as quickly as humanly possible, which can lead to its own set of problems.  The latter option will surely lead to increased frustration, potential loss of customers and/or future projects, and time delays in orders of magnitude longer than simply being prepared.  In short, there are two easy things you can do to minimize this damage caused by a downed Cube.  Set and know expectations with end users, and have backup servers and configuration files.