Shortly after I was hired as an IT manager, my employer's revenues began dropping due to a market shift, causing my department's workload to drop. Several people were laid off in all departments including mine. Rather than wait for my entire department to be eliminated, I decided to do something about it. I decided to make my department more valuable by helping the company operate efficiently with its reduced staff.
The company for which I worked ran a call-center business that took orders for mail-order companies. These orders were captured by our telephone operators in our system and then transmitted to our clients' warehouses for them to ship the ordered merchandise. My department's job was to handle hardware and software needs related to these activities. This was quite a workload. Although our duties were diminished, my staff was reduced disproportionately. However, by implementing good procedures and working hard, we were able to get our work done. Our increased productivity would have invited more staff reductions if we had used the efficiencies to work fewer hours. Instead, we started new projects that expanded our department's job description.
Since the number of clients had been reduced, I decided to expand our client list to include the other departments. We would develop software for them to be able to operate more efficiently with their reduced staff. They then would more effectively support each other and, ultimately, the company's clients.
New client needs
Having obtained new clients, I next met with the department managers to determine their data processing needs. Most had no idea what their needs were. Some had an awareness of their needs, but didn't have the language to articulate a request. So I began observing how they managed and shared data and eventually discovered their needs.
What I found from my observations was plenty of static and redundant data. Data was accumulated mostly on spreadsheets and in public folders. Files were typically read-only, preventing other employees from contributing information. Many documents weren't shared digitally. Instead, employees would print out reports for hand distribution. It wasn't that the information was private; they just didn't understand the potential of sharing data and didn't recognize the counter-productivity of their methods.
Let me say that this process didn't go smoothly. Although I had obtained the support of upper management, very few were cooperative at first. Some fought me all the way. It took time for most to comprehend database and data-sharing concepts. I also met with resistance from employees in my department. Some were not inclined to work hard to accomplish long-term goals in the face of so much opposition from outside our department. It pushed my management skills beyond my abilities. I didn't always handle myself well and at times I made the situation worse. It was frustrating and caused me to jeopardize my job. Nevertheless, for the good of the company and the very people who opposed me, I had to risk alienation and endure the abuse.
Leading by example
Since all employees had experience with the Web, we decided to develop a system that would be interfaced through the browser. We set up an intranet (with MySQL for handling the data) that could be accessed from inside or outside the network. Next, we created an opening Web page with links to a page for each department.
To give nontechnical employees an example of what could be done with an intranet, we first built the IT department's section. We set up tables in MySQL to keep track of our data: We had tables of data on every computer and tables on the clients. With these two sets of tables, we developed CGI scripts to access and manipulate them. Next, we developed a work request program for employees to make requests for computer repairs or client software modifications. Finally, we developed online procedure manuals for our use and for nontechnical employees.
The result of setting up place holders on the intranet for each department and developing resources for my department was that the other managers began to see the possibilities for their own sections. It also helped them feel comfortable with interdepartmental data sharing. They were getting the idea and beginning to discuss their data needs in a useful manner.
A common thread
Once the concept of an intranet for managing and sharing data began to be understood and accepted, we were ready to start developing online applications for key departments. Since we were a call-center, data gathering for all departments was primarily related to the telephone operators. Human resources was a good starting point for an interdepartmental system. There was plenty to do in HR, but initially we focused on basic employment data. Once their data was converted to MySQL, we then developed screens that listed operators, with links to detail pages on each. It took some doing to convince HR that the sensitive pieces would be secure so that we could share their other data with the other departments. But eventually we were able to satisfy them and move on.
Next, we developed a system for the training department. Previously, HR would give training a printed list of newly hired employees that needed training. A trainer would then type the names by hand onto a spreadsheet for record keeping and planning. With the new system, when the trainer prepares for a class each week, she pulls up a page on the intranet that lists newly hired operators. The list shows information that she needs to prepare for her class. It also includes the type of operator trainees are to be so that they are trained in the appropriate systems. After each block of training is completed, the trainer then opens an online form to make comments on each employee. These records are shared among the trainers and are also viewed by the call-center supervisors to see what to expect from the new batch of operators.
As new employees near the completion of their training, the scheduling department opens a screen in its section of the intranet that provides a list of newly trained employees. This list is part of a larger list of all operators that are available for work, including each person's skill level. From this list, the scheduler schedules a good mixture of operators to meet expected caller volume.
Once the schedule has been set, in the call-center section of the intranet, the call-center supervisors can open a page showing all of the employees who are scheduled to work each shift of each day of the week, along with other related data. Again, this information comes from the HR records, the training records, and the scheduling records.
Finally, the operators have their own section of the intranet. They can check their schedules from home or work on their personal page. It shows the training they've completed, their schedule for follow-up training, messages from their supervisors, and a link to a bulletin board where they can give feedback to management. Also, it contains information about new products and special notices from the clients. And from their page, the operators can also launch into the order-entry system to take a customer's order.
What we gained
By finding the main chunk of data (in this case, the operator records), we were able to begin to develop a system that would bring all of the departments together, and we identified inefficiencies and redundancies quickly. This allowed the users to benefit from our efforts sooner, and it recruited nontechnical personnel to promote the intranet system. Once we were in full swing, my department was kept quite busy. We couldn't develop scripts fast enough to meet the requests from the other departments. As a result of redefining my department's job description and expanding our client list, we became greatly intertwined with every aspect of the business and a more valuable resource to the company.