In 1998, I started College in Computer Information Systems at Indiana Tech in Fort Wayne, Indiana. One of my scholarship requirements was to take on a certain number of hours with an on-campus job. I ended up working in the cafeteria as a food runner, and I also worked in the maintenance department doing everything from carpet cleaning, floor waxing, lawn-care to maintaining and designing FileMaker Pro databases. In the second semester of my freshman year, Cory, a senior, was to be graduating in May and he had been working in the maintenance department as well and helped the Maintenance Director with a FileMaker Pro "Key Database". It was a database that tracked all the keys and locks on the campus. With Cory on his way to his to be stellar career, he needed to train someone to be able to help with the maintenance of the database. Since I was in the CIS program, he thought it would be a good fit.
The database itself was pretty basic but with the FileMaker Pro tools it was much better than a spreadsheet. During the training, Cory explained how everything worked and even a few ideas he had to improve it. During that summer break, I continued to work on-campus in the maintenance department. During that time, I made a few tweaks to the "Key Database". I got to know many of the maintenance employees better and through that, I discovered several areas in the department that wasted significant time.
Two tasks I thought could be improved with a FileMaker Pro database was incoming package tracking for students calling to see if their package had been delivered yet and purchase order tracking. So, with the approval of the maintenance director, that Fall I dove into two FileMaker Pro projects when I had time between my other duties: Package Tracking Database and Purchase Order Database.
Package Tracking Database: The existing process of receiving packages was to record each package on a paper list form on a clipboard. We recorded the date, shipper, receiver, number of packages, tracking number and comments, like who the student was and if they were notified. The initial idea was to simply move all this information to FileMaker Pro and add a barcode scanner to capture the tracking number. This would instantly get us off paper, provide quicker & more accurate recording of the tracking number and the ability to search by any of the fields. Once we setup another Apple IIe in the receiving "office" and got the barcode scanner working, I added other features like drop-down lists to improve consistency and reduce data entry, several reports, a field to indicate which building the package was delivered to and even a hyperlinked tracking number to the UPS or FedEx website for tracking details. Now when students called to check on the delivery of their package, we simply entered their tracking number to look it up. I had more ideas like an integrated Staff and Student phone directory, so we could pick the student from a drop down and give them a call or send them an email. However, that was my first practical experience with the concept of referential integrity, not so much in the technical sense but practically of not having a reliable staff and student directory that didn't create redundant records. Overall, this was a huge success and really improved the receiving and tracking of packages.
Purchase Order Database: With the success of the first database, I dove into Purchase Order management. At that time, the school used preprinted three-part PO forms and as a control, the accounting department issued each department a stack of PO forms from time to time. They needed to use the forms for day-to-day purchases and distribute the parts accordingly. Some of the issues with these forms included everything from the lack of quick traceability to messy handwriting. The solution really cleaned things up.
First, we established the PO number control. When accounting issued a batch of PO's, we entered the first and last PO number and a FileMaker Pro script auto-generated a PO Header record for each and assigned several defaults: status, date of creation, etc. Next, we built out the statuses that would be valuable, such as unused, issued, void, open, closed and received. Then we needed to create a Supplier address directory so users could quickly select the supplier, but they could optionally manually enter the supplier information if it was not a common supplier.
After we duplicated the Purchase Order detail fields from the actual PO form, I dove into the printing of the PO on the three-part form via the Apple Dot-matrix printer they had. This was where my distain for printers began- if only it didn't have to be printed and lined up perfectly the project would almost be complete. This step seemed to take the longest time, but we finally did it and after a trail period with the Maintenance Director and another employee. Then, we trained others and really improved the process.
Late in the 2000 spring semester, budget time was quickly approaching so I set to work on creating reports and several other ways to search the PO data. These reports gave the Maintenance Director a very quick way of reporting on the department's purchases over a time period and saved days of time collecting and calculating each maintenance category. The Maintenance Director was able to attend budget meetings with these reports in hand and be able to quickly answer questions and saved time in the budget review process.
Student Phone Codes Database: Around the same time, the school wanted to offer students a cheaper alternative to phone cards and had setup a new module on our on-campus exchange that would allow students to have a long-distance plan at the price of 10 cents a minute through the school by entering a PIN from their phone and then dialing the number. However, we needed an easy way to track the PIN assignment by Student Name and Extension. It was common for students to change rooms and as a result, their extension and the Phone Manager needed an easy way to track this information so he could reassign PIN's. This database was pretty simple and just consisted of a few tables to track the Extension master, PIN master and then a quick way to mass update Student names. I also created a few reports so the data could be printed out as a reference when updating the Exchange. At that time, the phone system did not have some of the nice user-friendly features that we have today with VOIP and such.
Attracting Attention: By this point I was becoming concerned about the reliability of the various computers that these databases were scattered on. If any of these computers died, there was not much certainty that the data could be salvaged quickly. From time to time, the Maintenance Department would inherit older Macs and it was time consuming to move the databases around and there wasn't a central PC to do the database work. What we needed was a network. The campus had a network; however, the Maintenance Building only had a few connections to it, and I needed about four more. If we could get all these Mac's connected, then I could setup one of them as a FileMaker Pro server and get all the data in one place.
The Maintenance Director spoke with the IT department to see what we could cobble together. This of course sparked some concern about what I was up to. After several conversations, trips under buildings and above ceilings we ended up with the connections we needed, and all the FileMaker Pro databases hosted on one of the IT Mac servers with nightly backups. It was a lot of work, but it was worth it, the databases were shared and safe. I didn't realize it at that time, but I had started to create an information system as I was pondering how these databases could work with each other. I now had a student phone directory; couldn't I get the receiving database tied into that? But before I could get too far, I was distracted by the poor condition of our school website.
One day, I suddenly realized I had never been to our school website. While working in the maintenance department, I punched it up and I was shocked. It was a mess. Now, if Indiana Tech hadn't been a technology school, it wouldn't have bothered me, but we offered degrees in computer science and yet we couldn't do better than this?
I expressed my distain out loud, and the Maintenance Director heard me. He agreed and I asked if we even had a webmaster. He said that he thought we had recently hired an alum as a professor that would also be handling the website, and I should speak with him about what I thought. So, I did, but I didn't know how long he had with the site or even if he had done anything, so I wasn't sure how to say it, but I had a bridge, because he was scheduled to be one of my professors next semesters.
Tom Brownridge was to be teaching the Problem Solving for Programmers course (which ended up being one of the best courses I took). Anyways, the conversation went something like this:
Me: Prof Brownridge, so you're teaching the Problem Solving for Programmers course next semester, I'm looking forward to it. I also heard you're the new webmaster.
Tom: Yeah, that was just assigned to me as well, I haven't been able to get into it yet.
Me: Well, it's pretty bad and needs a lot of work.
Tom: I've heard that, need a job?
Me: Sure, but I haven't done anything with HTML.
Tom: That's ok, I haven't done much either, besides, this is college, we teach people things, and you're going to need an internship soon, aren't you?
Me: Yeah, I hadn't even thought about that.
Tom: Let me talk to some people and see what we can do, because I think I'm going to need some help.
Me: Ok, thanks, let me know how it goes. I left with a sinking feeling, I was just pulling things together for the Maintenance Department, and they were a great bunch to work with. What if I couldn't pull off this website stuff, I didn't know the first thing about it. Oh well, I guess I'll wait to see if Tom can even work out anything.
Next: College Internship