Back from the Front: The IT Battlefield
Like a conquering hero returning from a grueling campaign in the far off land that is called Georgia, I have returned victorious. I am not new to Engineering. I am not even new to the office. But it has been a while since I have been here.
For the past year and some months, I have been working with a global pharmaceutical leader specialized in treating rare diseases. The plant I was stationed at produced immunoglobin and albumin; in other words, serious stuff. My task was to train their end users on how to use and validate their Electronic Batch Records (EBR) software. A little about the software: it is the central unit in the production software at that plant. Every other software communicates with it in some form, whether it is who pulled the samples and when to inventory adjustments for materials used.
Every project has its challenges, and then you come across a few surprises. Trying to get people to like a piece of software that someone else has designed is almost like trying to teach a cat tricks. Going into it, you know it will not be easy, and you might question if it is even worth it. But in the end, you will be glad when you are successful and the customer is happy.
I have spent a lot of time digging through configurations, figuring out what happens when this happens or if this does this, then what does that. And at a basic level, that is the basis for Software Validation. Every pathway must be tested, every button has to do what it should do, and there is no taking anything on faith. There is a great reason for bringing someone like me or anyone else on the Engineering team to test, even (and especially) if we did not write the process instructions. Because when we are left with instructions for validation, we follow the tests blindly, which oftentimes leads to us finding a problem in either the software or the test case of which no one else was aware. After many grueling hours testing the instructions, we finally create a product ready for use. Our time breaking the software can now be spent helping production fix it when something unexpected happens. During production runs, I was a key member of the support for the software, and at 0215 when something broke down, I would be the one called and asked “What do we do?”
Eventually, all projects end. Manufacturing was trained how to correct when things did not go as planned, communication between the different systems was going strong, and I had finally earned my parole.
Meet Scott Scheeringa
Where You Were Born/Grew Up: Highland, Indiana
Your Education: Bachelors of Science in Computer Science from Indiana University
Your Title: Senior IT Analyst
Your Practice @ Engineering: Manufacturing Operations, Software Training
Your Office Location: Chicago, USA
How Long You’ve Worked @ Engineering: 3 years (as of October 2017)
Your Areas of Expertise: IT Support and Software Training
Coolest Project: Every couple of weeks, I was somewhere else, making new introductions and training new individuals on a new piece of software (for them). This project allowed me to create and train a support team to help with any issues any of the plants would face.
Your Career Goals: I’ve been studying Project Management in my personal time, and I hope to one day become the go-to person for developing training plans and support for a multitude of different projects.
Best Thing About What You Do: I get to work closely with people learning different processes of manufacturing. And hopefully, I teach them a few things along the way.
Your Personal Interests: I read a lot, mostly fiction, play games, and generally enjoy life.
Favorite Movie of All Time: It’s a tie between The Princess Bride and Starship Troopers.
