Note: IS is an exciting field and there are many career opportunities for our graduates. Despite the diversity, students often ask "Exactly what does an entry level systems analyst actually do?" This essay was written by a former systems analyst. She writes about her first two years of work experience after receiving a BS degree in business administration.

I received a job offer from a large petroleum company during my senior year in college. Upon hearing the news of the offer, my mother said, "That's wonderful darling, but what's a systems analyst?" At the time, I really didn't know!

Three weeks after I graduated in May, a big moving van collected all of my possessions, including my new car (my first post-graduation debt!). I flew on a plane to Houston while the van made its way south. I did not know anybody in that city. My only contact was an employee that had called me a few times. I knew his name was Fred and I thought he was another systems analyst. When I arrived in the city, I called Fred and he invited me to meet him at headquarters. To my surprise, Fred had a huge corner office on the 25th floor--he was a big-shot manager, not another systems analyst. Fred introduced me to the people in human resources who helped me find and apartment and get situated.

Once settled from my first big move, I had to make another major life adjustment--I was expected at work at 7:15 a.m.! The first few weeks, I was enrolled in various training classes on the petroleum industry as well as technical classes on COBOL and JCL. During this time, I got to make friends with the other 60 new hires. (I said this was a big company).

Most of the first work assignments for the new hires were support of existing systems. My first assignment was on a development team to replace the entire accounting and operating system for the company. There were 70 people on the project, divided into various sub-groups based on business functions, such as accounts receivable, inventory control, accounts payable, general ledger, chart-of-accounts, etc.

I worked on the inventory control subsystem. My team consisted of a team leader--another analyst with 5 years experience, myself, and a full-time user, Ed. Ed used to run one of our largest pipe and wellhead warehouse in New Orleans, but was re-located to Houston to work on this project. He had over 20 years with the company. The goal of our subsystem was to reduce the $1 billion in surplus inventory due to poor business processes. There were over 2,000 warehouses (some are very small, basically a pile of pipe next to a drilling site) and 300,000 material codes. My first job was to understand everything about pipe and wellhead warehouses, including how material is ordered, received into inventory, inspected, tracked, transferred to the drilling sites, etc. Ed and I spent six weeks in a large conference room drawling data flow diagrams of the processes. Then the project leader quit and there was no immediate replacement. (Boy did I panic). I decided that I had to go to the warehouses because I couldn't conceptualize the business from the data flow diagrams. (Plus I was excited about going to New Orleans).

My senior supervisor said I could go to Midland/Odessa (this was less expensive than New Orleans). This experience was a shock. I showed up at the warehouse in a suit and heals, expecting a clean building with conveyor belts and fork lifts. Instead it was a huge dirt lot with a fence around it. I followed the warehouse personnel and began to appreciate why the accounting systems were so messed up. These people were so busy hauling and inspecting pipe (with big water-pressured machines), that the paperwork was the last thing they did each day. They had to fill out forms and have to remember the material codes for everything that went in and out of the warehouse that day. With 300,000 material codes to choose from, that's no easy task. If they don't know the material code, they have to write out a detailed description, such as the weight, grade, thread, length, condition code, etc. After that trip, Ed and I had a much better time communicating.

After starting to design the inventory control system with Ed, I learned the true meaning of the word "integrated system". We always had to communicate with the other sub-systems. For example, the purchase order sub-system wanted to use a new material catalogue, which would affect everyone of our programs. The chart-of-accounts sub-system wanted to create new accounting codes, again effecting the design of every one of our programs. We all had to keep in constant communication and there were scabbles as to who would change what. (I.E., everyone wants the other team to accommodate them.)

To make a long story short, midway through development, the company decided not to build the system from scratch, but to buy a software package and customize it. We waited 4 months for the contract to be negotiated and signed. With the prospects of nothing to do until the new system arrived, our senior supervisor created "RAMBO" teams to design, develop, and implement little fixes to our current system. The inventory control team (which had a new project leader, yeah!) began designing lot's of little things to fix. We bought a Sales and Use Tax table and wrote a program to automatically calculate the right tax for material transfers. (The tax laws are so complicated that we were paying taxes "just-in-case".) We also built and electronic data interchange to a company that tracks current market prices for pipe and wellhead. This was great because the accountants used to have to keep tons of catalogues in their office to look up prices. We wrote another system to immediately put joint interest checks in a bank (an electronic funds transfer). (Actually these projects took more than 4 months, but you get the idea).

While working on the development team, I also had other duties. I was the data dictionary co-ordinator. That meant that as project teams started identifying new data items, I had to give them a valid name and enter it into the dictionary. I also provided reports for the database design team who had to logically order all these data fields.

I was also the security request co-ordinator. Everytime someone wanted access to a data set, I had to verify that they have a legitimate need to either read or read/write to a dataset. I passed the paperwork to the Security Administrator.

I also had to give lots of presentations to other project teams, supervisors, and users. At first I was so nervous about these public speeches. But I joined Toastmasters and learned to really enjoy talking in public. That was a vital skill to learn because that's about the only time senior level people are exposed to the analysts, and they are the ones who ultimately determine performance ratings.

In summary, my first two years as a systems analyst were very exciting. I spent most of my time talking with users to understand the business and to other analysts to ensure compatibility between subsystems. I did a lot of design work, and created documentation for these designs, including reports, input forms, and programming specifications. I coded some of the programs myself (in COBOL and PL/1). I learned how to test systems as well as implement them. I did some technical writing by documenting new systems, including technical documentation and user documentation. The best things I loved about these two years was making friends with all the other analysts (work was very social), learning all the time about both the business and technology, meeting new challenges such a public speaking and learning to adjust my "technical jargon" to my audience.