Anticlue

Look at the whole ball of wax

Yesterday was an interesting day work wise, I started off the morning doing an analysis of where my team spends their time. It is a part of the monthly routine, I'm trying to standardize. One of my foundational beliefs, is that we work to improve or enhance the place we work. So my goal is to have us spend a large portion of our time doing projects enhancing systems and work processes. When items are built, it should be done in an automated fashion, so we are not constantly having to spend resource time, operationally maintaining a system. Ideally, the business partners are also not to spend a great deal of time operationally maintaining a system.

The truth of the matter is that uninformed programmers may have different goals than the organizational goal. The other item is that timelines may have been rigorous and the end product is a manual interface. Sometimes the individual tasked just doesn't have the needed skill, or sometimes there is the niche builder who creates a niche of dependence for job security. There can be and are alot of reasons, and inheriting a process afterward is enlightening to say the least.

So yesterday, in my analysis I found we were spending the same amount of time resolving break fix items as project work. In my head, and due to the type of organization we have, I believe this should be a 2 to 5 ratio versus a 1 to 1. So it was a challenge for us to identify the root cause and fix the process at hand, and low and behold two main items came up. Both I'm going to share, just mainly because there are times I need to remember the high points.

First, we have an inherited manual process to generate the patient days and patient census, for the week and month. The code is even to the point where portions need to be highlighted, run, results checked, and then depending on the results another portion checked. The data extraction, load, extraction is mostly automated, with several uncontrolled breakpoints that a dependent on a string of processes, so it needs re-engineering. The reporting is all manual, and will need to be moved to another tool inorder to automate CF7 or Crystal Enterprise. Surprisingly even the extraction query for the report is also manual. Any way, the previous programmer built a table that needed to be updated yearly. The really frustrating part that cropped up yesterday, was that it needed to be updated yearly with the following information.

Days Month Year
31 January 2006
28 February 2006
31 March 2006

I think you get the general idea, and definitely not the way one should continue going forward. So we had to change the process, but the table was filled with yearly month days from 2001.

And a key item here, is that patient days and patient census, are pretty standard needs within a Registration/Billing System, why do we even have to do this in a separate and distinct system? So the investigation will continue to find what was the root cause to create this system.

Another process that has been manually done from 1999 was also identified. It is an interesting mix and done daily.

First, we take the data from an operational data store and place it in a file.
Then, we have a scheduled vb program on another machine which copies the file from one server to another.
Next, we have another scheduled vb program on another server, different server from previous step, that takes the file, strips off the cpt code and date of service and uses access 97 to create an autoidentifier. A file is then created with the autoidentifier instead of the cptcode and date of service.
Next, a person manually copies this file from the place it is created to another server (which is a development platform).
Next, the file is encrypted on this testing server and ftped to the remote site.
Next, the ftp program checks to see if any files are available for download and picks them up, unencrypts, and sets them on yet another server. (Autoidentifier is no longer on the file)

We are still trying to discover what happens to the file after this point in time, but it looks like all we need to do is get the current specs of the output file from the receiving system and just write code to get it from the data store, and send it encrypted to the end location.

So the lesson learned here, is that you have too look at the whole process the sum of the parts, and streamlining may be simplier. While fixing these two of many processes are not resume worthy by any means, to me it is just a couple of steps closer to the ideal, and our team has truly started to adopt the philosophy.