Although we’ve made organizational and technological changes in the lab to monitor cases more closely and reduce mistakes it was still too easy for a case to “fall through the cracks”.  There had to be a system in place to make sure that cases didn’t fall behind in scheduling without being addressed.

Initial Situation:

Our philosophy (at least when it comes to customer service) is “Anything you address up front makes you look like a genius, and anything you address at the last minute makes you look incompetent.”  It is with this idea in mind that we decided to create an “Early Warning” system so that we could further reduce cases falling out of the workflow and increase doctor contact to minimize problems.

Each case within our laboratory is scheduled in a series of steps assigned to days, with the day of receipt being “Day 1”.  Each technician is responsible for checking the case through to the next step when they’re done with it.  Each step is assigned XX minutes for completion.  The last step in each case is “Shipping”.  The system is also smart enough to know what days we work and what days we don’t – so a weekend day with no one working is not counted as a “production” day.

If we imagine the following schedule:

  • Day 1: Model Work
  • Day 2: CAD Scan and Design
  • Day 3: Milling
  • Day 4: Finishing
  • Day 5: Shipping

We can then imagine that if it were Day 2 and the Model Work step had not been completed then this case is behind schedule.  What we needed was a system that would bring this to our attention as early as possible.  Further, with the volume of cases that we handle in the lab we don’t want cases that’s are “on time” to become noise and keep us from seeing the problems.

We run a server-based locally-hosted software system that is industry specific (typically referred to as “made to manage” software) and it runs on a SQL database on Windows Server and uses Crystal Reports as it’s reporting tool.  Crystal Reports is not my favorite tool because it basically requires programming knowledge to create a report, but I understand why the developers use it and I love them all the same. The software vendor can make a custom report for us to run on a daily, weekly, or even hourly basis but we end up needing someone to either (a) receive the report and review on schedule or (b) have someone print the report so anyone can look at it.

That doesn’t work for me.  My primary objection to this is the captive nature of the solution: it requires someone to be somewhere at a certain time – every time – for this to work.  My next objection is that I like trees and the paper usage would be abysmal.

Attempt #1

I was lucky enough around the time to come upon some commercial displays for next-to-nothing from a friend.  If you’re not familiar, commercial displays (like this NEC 32″ display) are digital displays that are designed to be “always on” – unlike traditional monitors.  The internal components are designed to take the abuse that comes from years of operation and never turning off.  The units I came upon were older and bulkier than modern displays, but they inspired the solution that I settled on.

If you’ve read my blog at all you’ll know I’m a big fan of emerging technology, especially low-cost solutions like the Raspberry Pi.  This little device runs a bare-bones Linux install called Raspbian but includes a Windows-like GUI interface that can do things like run a web browser.

With the assistance of the Development team at Atlanta Based Systems (the authors of our lab software) we were able to create a report that listed our cases in a way that we wanted. We then used Visual Cut Pro to schedule the report and convert it to HTML.

I did some basic programming and modification to the Raspberry Pi to have it boot as quickly as possible to a web browser in Kiosk mode (full screen, no buttons, no address bar, etc…) and to display the HTML output of the crystal report.  The Raspberry Pi was modified to never blank the screen, to hide the mouse cursor when not in use, and to allow remote access for maintenance beyond what SSH could do as well as a few other hacks.

Problems with this Method

The first major issue with this method is Crystal Reports (CR from here on).  CR’s first job is obviously not HTML output, and it’s certainly not good HTML output.  CR is designed to create reports for paper, and has such has certain limitations.

This is an example of what might be seen in the Removables Department display.

There are ways around this, but it requires lots of text replacement during the conversion process.  Good HTML output is responsive to the display size.  In this scenario we had to define our “paper size” as roughly the dimensions of the screen resolution.  This took some serious finagling to create a decent output and we still ended up with some weird quirks.

Next, we have the issue of the stability of a $35 development platform running all the time.   The Raspberry Pi was designed as a basic PC for schoolchildren in Great Britain, but it’s low cost and extensibility have made it the darling of many hobbyists and makers.  I was asking the PI to run 24 hours a day, 7 days a week, and to refresh the page every 180 seconds – and to do so over WiFi.  This caused some problems in terms of stability (the device would lock up and have to be manually restarted by pulling the power cord and plugging it in again) and access (weak or interrupted WiFI would cause a 404 Error and network instability would sometimes cause the request for the file (although NOT being served by a web service like LAMP or IIS) to fail and return a 500 Internal Server Error.  Either of these errors would stop future refreshes from occurring.

It would be possible to manually program the Pi to reboot or kill and restart processes multiple times a day to reduce these problems, but it seemed a poor choice as we were now getting in to the programming game – and that’s not a game I want to be in.

I have since had to upgrade to more stable technology for the brains of this operation.  I chose the Intel Compute Stick to replace the Pi, and I was able to use Task Scheduler to schedule reboots and to quickly kill and restart the Kiosk operation multiple times per day without noticeable interruptions.

Future Development Plans

I’ve spoken with the developers, and although they would like to stick with the Crystal Reports based solution (due to the fact that they can modify and create new reports for this method at any time) I have decided to look at developing in a ASP/SQL environment using dynamic refreshed of data.  The plan is to create a single modifiable interface that can be modified and sorted in several different ways.  These “profiles” can be saved and shared between machines so that consistency of presentation is maintained.