|
|
|
|
|
|
|
Annals of Reengineering
MIT’s Reengineering Project – with capital letters on the "R" and the "P" – technically ended June 30, 1999. The Faculty Newsletter has asked me to write about whether Reengineering was a success, a failure, or something in between. I worked on the Project for its last several years as the head of the Community Involvement team and have written regularly about Reengineering for this and other campus publications.
My personal view is that although MIT’s Reengineering effort accomplished some critical work in improving administrative processes, we were not able to achieve all of the Project goals. I think it’s safe to say that everything MIT tried to do in the Reengineering effort was harder and took longer than anticipated. And even though Reengineering is over, MIT is still very much in transition. Tools such as SAP have not been easy to use, and the learning curve has been steep. In fact, some administrators would probably tell you they have more work now than they did before Reengineering began. But it’s also important to note that the various tools initially provided by Reengineering continue to improve, and staff throughout the Institute are becoming more adept at utilizing them.
There is certainly more to be done to simplify and improve the quality of administrative procedures at MIT and some of that work, such as in Financial Systems Services (FSS) and in the human resources area, continues. [FSS was described in the April 1999 Faculty Newsletter.]
It is also worth noting that Reengineering has had an important impact on the ways people work at MIT, and this goes beyond the many employees who served on redesign, implementation, or support teams. For example, the idea of focusing on "customer service" was fairly foreign to the MIT culture when Reengineering began. Now, many people know and understand that serving clients well is a basic part of their job. In addition, many staff members developed skills in project management, running effective meetings, and collaborating with people whose expertise is different than their own. These cultural changes may be as significant, long term, as the more tangible accomplishments of the project.
This article will review some background on the Project, the original goals, what we were able to accomplish, what wasn’t done, and why. Costs and savings estimates are also included.
Background
As many of you probably remember, Reengineering at MIT was begun in response to the growing gap between the Institute’s operating income and its expenses. Even after the budget cuts that were planned for fiscal years 1994-96, the Institute was forecasting serious operating gaps. Since the vast majority of our budget is spent on salaries, wages, and benefits, MIT needed to become smaller in terms of staff. However, the senior administration decided that simply cutting positions, as had been done in the early 1980s, was not the best way to proceed. That experience had shown that eliminating jobs without changing the work resulted in a steady regrowth of positions until, a few years later, we roughly matched the staff size before the cuts. Instead, senior leaders decided to use the principles of Reengineering to help us take work "out of the system."
The Institute also wanted to demonstrate an organizational commitment to containing costs and managing resources carefully so that when a parent, a donor, or a sponsor asks, "Are you managed well?" the response would be positive.
The Reengineering Project began with some fanfare. There was a special edition of Tech Talk (on November 22, 1993) and a community-wide Town Meeting the following week. The special issue of the paper focused on the deficit and introduced the concept of Reengineering as being central to correcting the imbalance. Not surprisingly, what got the most attention in the community were the "Goals of the Plan," which were to "reduce the operating gap by $40 million ($25 million net of indirect cost recovery) and operate more effectively with a smaller work force." One estimate was that 400 positions would be eliminated.
Looking back, it’s pretty clear that the announcement about savings and job reduction targets created a variety of problems and barriers for the people who were ultimately asked to redesign administrative processes. I believe that the senior administration hoped that the MIT community would pull together during Reengineering and work for the collective good of the Institute. However, when people felt that their jobs and their livelihoods might be at stake, many were less than anxious to embrace the Reengineering concepts or the redesigns that might put them out of a job. In a numbers-oriented place like MIT, it’s not surprising that the target goals were announced, but it’s important to remember that they had a serious impact on the work that followed.
Early in the Reengineering effort, Sloan faculty members were approached about assisting with the Project. But since they did not want to consult "in their own backyard," an outside firm, CSC Index, was brought in to help. This angered many in the community, but MIT leaders believed that we needed some guidance from people with experience in Reengineering and managing change.
For these and probably other reasons, Reengineering became kind of a dirty word at MIT. Anything that people didn’t like was attributed to it, and the Project divided the community rather than pulling it together. Despite our best efforts to involve people in the work and to communicate what was going on, perceptions such as the following were fairly common in the community:
"Things were fine as they were before, so why do we need to change?""I don’t understand what Reengineering is trying to accomplish."
"I can’t afford to lose my job!"
"Who do these Reengineers think they are, trying to improve how I do my work?"
"If they weren’t spending so much money on consultants, then maybe MIT wouldn’t have to lay off anybody."
"My department head doesn’t seem so keen on Reengineering, so maybe we can just duck and we’ll be spared."
Genesis of the Project
The Reengineering work actually began in March of 1994, as an eight-member Core Team started to identify and map the Institute’s key administrative processes and recommend several for the initial redesign efforts. The Core Team analyzed major processes on the basis of cost, impact on revenue, potential for improvement, significance of changes to MIT’s future, and the ease of implementing changes.
The six areas initially selected for redesign included facilities operations, the mail service, supplier consolidation, management reporting, information technology, and the appointment process. The two other major areas that were added to the Reengineering effort later were student services and human resources. In addition, there were "enabling" teams such as training and development, community involvement, and the help desk.
And What is Reengineering?
Here is the definition of Reengineering that MIT used: "Reengineering is the fundamental rethinking and radical redesign of support processes to bring about dramatic improvements in performance." Good support processes were defined as being simple, lean (with little non-value-added work), results-focused, and consciously organized to achieve goals.
The method MIT used in its Reengineering work was to appoint redesign teams whose members either had expertise in the area and/or who were "customers" of the particular process. The teams were charged with analyzing the processes and proposing a redesign that simplified the procedures, reducing handoffs and the possibility of error. In addition, customers and the bottom line should see improvements from the redesigns.
Most people in the community would probably agree that simplifying administrative processes while improving quality, enhancing customer responsiveness, and reducing costs was a tall order, but that’s what MIT’s Reengineering Project set out to do.
In order to evaluate the Project, it’s useful to have some context about the Core Team’s analysis of administrative processes at MIT prior to Reengineering. The table below characterizes pre-Reengineering procedures in the "From" state and indicates where we hoped they would be after the redesigns in the "To" state.
From To Fragmented and redundant
processes Integrated and streamlined
processes Most transactions treated as
exceptions Exceptions are
rare Narrowly defined jobs
focused on completing tasks Broadly defined jobs focused
on achieving results Policies and procedures
orientation Customer-driven Inconsistent, ad hoc job
training Continuous professional
development Administrators who
serve Managers who support and
partner Command and
control Empowerment and
accountability Ad hoc and anecdotal
measures Systematic performance
management Non-integrated, stove-piped
information Integrated, shared, and
accessible information systems
Though we’ve certainly made progress, we haven’t achieved the "To" state in every category.
What Specifically was Accomplished?
Physical Plant (now Facilities)
The most radical changes occurred in Physical Plant, now called Facilities. In terms of the number of its employees, Facilities is the most heavily unionized of MIT’s support areas. And most of its operations were reviewed and changed. In 1994, before Reengineering began, the total work force in Physical Plant was 587 employees, who were responsible for maintaining 7.47 million gross square feet of MIT space. Today, the size of the total work force is 550 employees, who are responsible for maintaining 9.3 million gross square feet.
The redesign of Custodial Services resulted in the formation of 26 self-directed teams who are cleaning an additional 300,000 square feet of new buildings with no increase in headcount. Weekday and weekend services were increased, again with no additional employees. Service measurements for quality, costs, communication with customers, timeliness, and safety were established and continue to be tracked on a monthly basis. Four supervisory positions were eliminated.
The redesign of Repair and Maintenance functions called for moving from a centralized to a zone-based system with teams of workers stationed in five zones on the campus. The resident team in each zone corrects problems in the following kinds of systems: electrical, heating and cooling, structural and mechanical, and plumbing. Customers report problems or make requests for routine service via a form on the Web. (Emergencies are, of course, reported by telephone.)
The mechanics have become very familiar with the buildings in their zone, and often spot potential problems before they become serious. In addition, the team members have a greater sense of accountability and connection to their customers. A survey was sent last fall to 500 customers who had requested Repair and Maintenance services. Of the nearly 300 surveys that were returned, 93 percent rated the service they had received as meeting or exceeding their expectations.
In the Grounds Services area, the redesign resulted in the formation of an Athletics/Grounds zone with new job classifications and descriptions, as well as four other Grounds zones across the campus. Staffing in each of the four other zones now consists of a gardener and four landscapers. Ultimately, six Grounds positions and one management position were eliminated in this section of Facilities, saving about $350,000 annually.
The Mail Services redesign, although initially unpopular, was necessary for the Institute in order to process our large volume of mail effectively, take full advantage of technology, and respond to both changing U.S. Postal regulations and changing requirements of the Institute. The redesign began with the hiring of a professional mail manager and the creation of a centralized Mail Services operation. In order to establish the new organization, union job responsibilities were broadened, providing for three levels of mail worker positions. The number of full-time equivalent staff was reduced by 10.5, with associated annual savings to the Institute of approximately $511,000.
The following are some of the specific changes in Mail Services. A new model for distributing mail began in the spring of 1995, and MIT now has 38 Distributed Mail Centers across campus, where customers have 24-hour access to their mailboxes. This model replaced an inequitable delivery service in which a portion of campus received desktop delivery, while at the other end of the spectrum some buildings received a single unsorted bag of mail. In July 1995, Mail Services implemented a new centralized outbound mail processing service that has helped MIT achieve a 2.5 cent reduction per envelope in domestic postage charges. (The department is now handling about 95 percent of MIT’s daily outbound mail from offices.) Mail Services also negotiates cost and service-level improvements for international mail and overnight carrier services. A new Central Mail Facility opened for operation in March 1996 in Building WW15.
The original redesign had shown that if MIT wanted to reduce its costs by bar coding and presorting outgoing mail, then Mail Services had to get its arms around that mail. This meant that its employees needed to do different work – essentially less delivering and more picking up and processing of outgoing mail. Some people in the community, including faculty members, have complained that asking customers to pick up their own mail from the Distributed Mail Centers is simply shifting work from central to local departments, and there’s some truth in that. However, the old "system" was broken. It consisted of an inequitable delivery service, more than 140 postage meters used by staff with little expertise, no volume discounts, and no economies of scale because the mail operation was so decentralized.
In addition to the $511,000 savings from staff reductions, annual savings of more than $490,000 have been achieved through minimized costs for presorted domestic mail, international mail, second class and bulk mail, the express courier contract, and the reduction of postage meter rentals.
Student Services
The establishment of the Student Services Center (SSC) was one of the most visible successes of Reengineering. Centrally located in Building 11, the Center offers students the convenience of "one-stop shopping" for many administrative services, thus reducing the need to visit numerous offices across campus. The SSC brought together staff from the Registrar’s Office, the Bursar’s Office, and the Financial Aid Office, with technical support from Student Information Systems.
Those who staff the front desk at the Center are cross-trained, so they are able to deal with a broad range of student questions. Another important improvement is that many of the frequent and basic student transactions were changed to be self-service via the Web, freeing staff to assist students with more complicated transactions.
Prior to the establishment of the Center, Student Services Reengineering teams had focused on all the business and administrative processes that students encounter outside the classroom. These included finding out about MIT and getting admitted, orientation programs, enrolling, housing, dining, paying bills, and paying students. Teams also reviewed academic support systems for advising, social support, and help with job searches, further schooling, and summer employment. Some of the Reengineering successes in this area include automated access to student financial and academic records, electronic pre-registration for courses, on-line graduate awards and appointments, and major improvements in loan and financial aid processing.
Another effort, involving Dean’s Office and Physical Plant staff, involved a facilities audit of all the space in the Campus Activities Complex, the Athletics department, and the residence facilities. The audit provides a comprehensive tool for making decisions about deferred maintenance and capital renewal. It details replacement value, provides a rating of maintenance needs (including, for example, life-safety and major mechanical systems), and gives the costs of repairs. All this information is housed in a Facilities database available to the administrators who make the decisions about maintenance and renewal.
Supplier Consolidation
The specific goal in Supplier Consolidation was to reduce the cost of purchasing goods and services while improving the buying process for the MIT community. The redesign called for eliminating steps and handoffs in areas such as finding sources, approving, pricing, ordering, receiving, and paying for goods and services.
When the project began, MIT was buying supplies and services from more than 14,000 different vendors, with about half of those involved in one transaction per year. That large number was partially a result of the specialized and often unique needs of Institute researchers. Nevertheless, purchases of routine goods and services were being spread out among far too many suppliers. For example, MIT was using more than 20 different agencies for temporary employees and consequently we were not receiving any volume discounts.
Another issue that was found prior to the redesigns was that purchases of under $500 represented only three percent of MIT’s business but 80 percent of the resulting paperwork. This was clearly an area that needed to be addressed in the subsequent redesigns.
MIT’s efforts in Supplier Consolidation include new ways of acquiring office and laboratory supplies, bottled gases, publishing services, temporary help, furniture, and computers and software.
The Office of Laboratory Supplies closed in July 1995, and MIT began partnerships with Office Depot in the office supply area, VWR for scientific apparatus and supplies, and BOC Gases for industrial gases. Although Lab Supplies had provided good service to the Institute community, the department had to mark up its costs in order to be self-supporting. The Reengineering teams who reviewed purchasing in these areas had found that large and specialized outside vendors could provide these supplies and services more economically and often with better delivery time.
As I noted in the November/December 1998 issue of the Faculty Newsletter, the Office Depot partnership got off to a rocky start, primarily because the vendor wasn’t sufficiently geared up to handle the initial volume of orders from MIT. However, once the start-up problems were resolved, the partnership has been working well.
After thorough reviews by two Reengineering teams, MIT decided to change the support services it provides for publishing. As a result, the Graphic Arts offset printing and binding operation was closed in August 1996, and Design Services was phased out of operation in fall 1996. (The Copy Technology Centers, which had long been the most successful part of Graphic Arts, continue as an Institute operation.)
The new organization that was formed is called the Publishing Services Bureau (PSB). Opened in February 1997, the PSB is an MIT service for coordinating the Institute’s print and electronic publishing activities. The staff of publishing professionals serves as advisors to help plan projects and as brokers between MIT customers and outside service providers. Bureau staff also work with MIT publishers to help them improve the effectiveness of their communications. In addition, efficiencies are achieved through more careful planning and the use of "smart" design and new technologies. Partnerships with a small number of outside designers and printers reduce overall costs through volume discounts.
A redesign of the MIT Computer Connection (MCC) changed the operation from a retail storefront to a Web-based electronic ordering and direct-delivery mode for computer and software purchases. MIT’s partner company is NECX. On-site pre-sales consulting and a product showroom remain available to individual and departmental purchasers.
By consolidating the number of external suppliers we use, negotiating volume discounts, and establishing partnerships with outside vendors, we are reducing not only our costs but also the paperwork involved in ordering and paying for these products and services. And, although the administration prefers that MIT community members buy from partner companies whenever possible, they are not required to do so.
The savings for fiscal year 1999 are still being calculated, but in fiscal 1998, the direct savings from the five major partnerships (Office Depot, VWR, BOC, Olsten Staffing Services, and NECX) were more than $1.5 million. (And that does not include what we are saving as a result of processing significantly less paperwork for purchasing transactions.)
It’s also important to note that the large MIT spaces formerly used for warehousing and selling office and laboratory supplies and for the Graphic Arts printing plant are now being used for other Institute purposes. The cost avoidance for all the spaces that could be reused as a result of Reengineering was calculated at $1.2 million.
Other Purchasing Options
Another Supplier Consolidation project was the development of ECAT, MIT’s electronic catalog. ECAT2 now integrates the partner companies’ Web-based catalogs and ordering systems with SAP at MIT for quick, all-electronic shopping and requisitioning by MIT purchasers. The vendors’ catalogs, with MIT-negotiated pricing, also have improved searching and browsing features.
Community members also have the option of using the MIT VIP credit card as another purchasing tool. Use of the credit card is helping to eliminate the need for many small-dollar requisitions and purchase orders, blanket orders, requests for payment, and petty-cash transactions.
Management Reporting and the Installation of SAP R/3
The installation of MIT’s new financial system, SAP R/3, was the largest, most expensive, and most difficult project associated with Reengineering. It also was probably the most critical. Even if MIT had not embarked on its Reengineering Project, it would have been necessary to replace and integrate our financial systems.
Many of MIT’s "legacy" financial systems were more than 30 years old and needed to be replaced. They were essentially a collection of minimally coupled, separate applications that operated on different computers. In addition, transactions were often entered several times in various central and departmental financial systems. This duplication of effort added to workloads, slowed processing, and increased the possibility of errors.
Because MIT departments are responsible for managing their own budgets, many areas had developed independent financial systems to monitor their expenses and uncommitted funds. While often very efficient in meeting the needs of a particular unit, the systems were not capable of interacting effectively across the organization. And, as both the central and local systems aged, they would have required significant upgrading of hardware and software. Rather than maintaining our old model of many distributed systems, the senior administration decided instead to focus on using a single, integrated financial management system.
Following an extensive review process, SAP’s R/3 system was selected to replace our general ledger, accounts payable and receivable, and procurement systems. Functions in the new integrated system also ultimately replaced EREQ and SumMIT.
The Management Reporting team’s role was to devise a process that would deliver to each Institute manager the information – financial, personnel, property, space, etc. – needed to operate the manager’s organization in an integrated, relevant, accurate, and timely manner. The idea was that MIT could improve decision making by providing consistent data and administrative processes throughout the Institute.
Difficulties in Implementing SAP
In the first few months after the central financial offices began using SAP in September 1996, there were some significant problems and delays in processing invoices. For the most part, these were caused not by SAP but by the methods we used to bring data over from existing systems. For example, in our old financial systems a vendor’s name was often entered differently by the various offices involved with invoices; in SAP, a vendor’s name must be the same throughout the system. Resolving difficulties such as this one became the primary task for the team, which delayed the rollout of SAP to the academic departments, laboratories, and centers.
Another issue that affected the rollout schedule was the concern raised within the MIT community about the visibility of purchase order data. The senior administration therefore asked Management Reporting team members to explore and present options for shielding such data. They found that MIT would either have to build an authorization structure outside SAP or build a significant modification to SAP’s structure to perform authorizations from within the software. Either of these shielding alternatives would have required a great deal of system maintenance, removed important SAP functionality, carried a risk of incompatibility with future versions of the SAP software, and increased the cost of the project. Furthermore, since SAP gives users the ability to get at certain data from a wide range of paths, we would never be sure that we had restricted access to every possible path to purchasing data.
Discussions with other universities that have "open" purchasing systems indicated no problems from open access. In March 1997, MIT’s Academic Council decided that we would move forward with SAP’s standard authorization system, which does not restrict access to purchase order data but does restrict access to accounting statements.
Some in the MIT community have expressed the opinion that SAP was not developed for decentralized organizations such as universities, and is therefore not as conducive to our work as some other system might be. However, the original decision to purchase SAP R/3 was made after a thorough review of our existing capabilities, our long-term requirements, and the systems available to ultimately meet those needs. We are working as a partner with SAP, which has further developed its funds module in response to our requirements.
An aspect of the SAP project that caused considerable upset in the MIT community involved organizational structures. Team members were asked to look at how the various administrative roles in the financial areas of departments, labs, and centers could be restructured for more effective work processes. One idea that was announced somewhat prematurely was the concept of an administrative "cluster," in which a team would provide relevant services to more than one department. Many administrators and some faculty members were very upset by this suggestion, because it raised both the specter of job loss and of radical change in work relationships. I believe the "cluster concept" was a major factor in community opposition to SAP.
As it turned out, simply getting SAP up and running was an extremely complicated endeavor, and the idea of redesigning how financial work would be done was postponed. (A variation of the cluster model is being tried in MIT’s Administrative Services Organization, ASO. This group was created by the dean of Engineering, then Bob Brown, when the administrative officers in the Departments of Chemical Engineering and Materials Science and Engineering both elected to retire early through the retirement incentive program.)
The complexity of SAP – like that of the other enterprise resource planning systems – created anxiety in the community for a variety of reasons. People had to learn new financial terminology in addition to learning the software because there wasn’t an effective way to retain MIT terms in the SAP system. However, the Institute’s development of the more user-friendly SAPweb application meant that the majority of requisitioners could use the Web rather than having to navigate the SAP screens to do purchasing. SAPweb allows authorized users to create, change, and display requisitions for both internal and external purchases.
Some community members in the departments, labs, and centers (DLCs) felt that the concerns of central areas were given a higher priority than the needs of DLCs as decisions were made about implementation. Although the DLCs were represented on teams considering several aspects of using SAP, the final decisions did not always follow a team’s recommendations. Clearer expectations, as well as better communication throughout that process, would have helped.
The pressure of the Year 2000 computer problem contributed significantly to putting technology solutions out ahead of people solutions. The Management Reporting team was pushing to meet deadlines while the DLCs wanted them to meet departmental needs. This resulted in a serious breakdown between key players on both sides.
How We’re Using SAP
The SAP software is now used in the MIT community for creating and approving requisitions (for outside purchases), journal vouchers (for transferring internal charges), and to manually set aside funds for anticipated future expenditures. A major advantage of an integrated system like SAP is that data entered once by someone making a purchase can be used simultaneously by all of the following: the outside vendor or partner company taking an order, the Procurement Office, Accounts Payable, and the general ledger. A requisition in SAP creates a commitment and a purchase order; the order is placed with the vendor; the goods are received at MIT; the invoice is paid; the account debited, and the account’s projected balance is updated – all without using interdepartmental mail.
The SAP software also is used for producing a variety of reports. A growing number of departments, labs, and centers are using the Labor Distribution System to analyze and manage labor and related effort costs. In addition, MIT’s Data Warehouse contains all the current SAP data and provides standard and specialized reports to authorized users. For example, a report called "Funds Available" shows cumulative expenses and revenues as well as authorized totals by principal investigator for a specific profit center or group of profit centers. Another report called "WBS Hierarchy" displays fiscal year-to-date and cumulative activity for a multi-level sponsored project.
Information Technology
All of the redesign teams used information technology (I/T) to help simplify work and improve service, but two of the teams concentrated on computing. They were called I/T Transformation and the I/T Infrastructure Readiness teams.
The Transformation team looked at changing how I/T specialists throughout MIT work together to operate and support the redesigned technology for administrative computing, help others use it, and add new features to it. As Professor David Litster said back in March 1995, "The guiding principle for administrative I/T is a partnership committed to a shared I/T mission of ‘Great Systems Fast,’ where ‘great’ is defined by the customer." Dr. Litster, MIT’s vice president and dean for Research, was the sponsor of the I/T Transformation team.
The new framework that was developed has process leaders coordinating the five major phases of I/T work. These include the following areas:
The Infrastructure Readiness team was charged with implementing the underlying computing software necessary to run the redesigned business applications both securely over the campus network and easily on administrators’ desktops.
The Appointments Process (TAP)
The TAP team looked at ways to enable MIT departments to newly appoint, extend an appointment, change appointment status, promote, transfer, place on leave, or terminate academic, administrative, support, and service staff. Goals of the redesign were to eliminate redundant work and unnecessary approval steps, eliminate paper and paper handling to the greatest extent possible, design an automated appointments system to support the process, and provide department access to data on appointments in process as well as to current and historical data.
However, the new process was still far too complicated and it didn’t integrate with our information technology architecture. MIT decided, therefore, not to implement this redesign. I have heard that the decision not to proceed contributed to some distrust of the process by team members and others in the community. However, a number of lessons were learned from the hard work of TAP team members, and they are being consulted by the discovery team that recently began work on investigating MIT’s requirements for a new Human Resources-Payroll system.
Human Resources
During the Reengineering effort, President Charles M. Vest stated that as one of the most vigorous research universities in the world, MIT’s continued success will depend on its ability to attract and retain not only the brightest faculty and students but also the best staff. Forces such as changing demographics, rapidly evolving advances in technology, an increasingly competitive labor market, and difficulties in juggling personal and professional commitments all contribute to making our work lives more complex. For that reason, MIT convened the Human Resource Practices Design (HRPD) team in June 1996 to look into the issues and challenges of our work environment.
The team identified areas of common concern across the Institute through broad outreach to many in the community, including faculty, support staff, administrative staff, and senior management. Basically, the Design team found that current human resource practices no longer aligned with the Institute’s changing environment. In partnership with the Personnel Office, HRPD then worked to define, test, and recommend appropriate HR practices. The scope of the work involved the following eight areas: HR practices applicable to teams; job design and classification; hiring procedures; compensation; employee recognition and rewards; effective performance evaluation; assessment, development, and training; and strategic planning.
The Reengineering Steering Committee then charged HRPD with forming project teams to develop specific programs on the following five topics:
HRPD has made recommendations on ways to improve our HR practices through an integrated, competency-based system. Some of this work is already being implemented and other projects are expected to be launched as pilots in the near future. For example, HRPD’s findings provided the foundation for the Classification and Compensation project in Personnel, which will reclassify all administrative staff positions on campus into a new classification model. The new model has six levels (down from 42 in our current classification system) and six "compensable factors."
As a result of the Reengineering efforts in the training and development area, MIT established the Performance Consulting & Training (PC&T) team, which is part of Personnel. The mission of PC&T is to work with departments, labs, and centers to enhance their abilities to achieve business goals. Services include the following: needs assessment, planning and measurement, process improvement, team development, custom-designed training, meeting facilitation, and resource referrals. The team also is responsible for offering a wide variety of courses for employees to develop performance skills.
During Reengineering, PC&T offered several workshops on Change Management and identified and prepared a curriculum for the core technology training that employees will need. The team also presented workshops on both giving and receiving a performance appraisal, and more than 1,000 staff members participated.
In spring 1996, MIT opened its Professional Learning Center, which is a multipurpose employee training facility in Building W89. The Center is being used for core technology training and other computer courses, SAP classes, and professional development seminars. Comprehensive training facilities like ours are rare in higher education. For example, of the 11 schools in the Boston Consortium (Babson, Bentley, Boston University, Boston College, Brandeis, Harvard, MIT, Northeastern University, Tufts, Wellesley, and Wheaton), MIT is the only one with such a facility.
What Did We Spend and How Much are We Saving?
The total one-time costs for Reengineering over the six years the Project ran (fiscal 1994-1999) were $65.2 million, with $41.8 million of that spent on upgrading our financial systems. Annual savings for the many processes and the reduced staffing that fell under Reengineering began to be realized in fiscal year 1996 at a rate of $3 million, and grew to $6.49 million in FY 1997, and to $11.4 million in FY 1998. In fiscal 1999, the savings rate exceeded $15 million per year. Although we would hope that the savings number continues to grow, even if it remains at $15 million annually, we will have paid off the one-time costs of the Project by the end of fiscal 2001.
Why Didn’t We Accomplish More and Save More Money?
Again, these are my own opinions, but with the exception of Physical Plant, Information Systems, and the Publishing Services Bureau, we did not reorganize areas. Instead, we put new processes back into old organizations. And though we installed new tools for doing financial work, we did not significantly change the way the work is done.
Particularly in the financial areas, we did not understand all the basic elements of our existing processes, many of which had become extremely complex over the years, and that led to errors and delays in implementing changes. In some cases, there wasn’t enough attention paid to the details.
It’s difficult to get people to do things in new ways when there are virtually no mandates. For example, efforts in Supplier Consolidation led to several partnerships (Office Depot, VWR, Olsten, and NECX) that MIT staff are encouraged – but not required – to use. The Institute could be saving more money if use of the partner companies was mandated because our volume of business with them would be higher.
There was uneven support from leaders throughout the Institute that resulted in a lack of alignment and confusion about whether MIT was really serious about wanting to change.
Another serious problem was that MIT didn’t do a good job of coordinating all the new initiatives – both from Reengineering and elsewhere – that were coming at the community simultaneously. For example, in addition to SAP, there were other new systems to learn like COEUS from the Office of Sponsored Programs and Brio Query for using the Data Warehouse. And, there were changes in how services were provided by Physical Plant and Purchasing, as well as a reorganization of the Office of the Dean of Students and Undergraduate Education. Consequently, many people felt overwhelmed by the number and the timing of all the new efforts.
Reengineering wasn’t a perfect methodology, but the senior administration believed that we couldn’t wait around until the perfect one was developed. As even its "inventors" have admitted, Reengineering didn’t pay enough attention to the people issues. If we had understood that better when we began, we might have started with redesigns in human resources, so people would have felt more supported before they were asked to undergo other administrative changes. In any case, we should have ensured that the early efforts were clear "winners" with the majority of the community.
What’s Still to be Done?
We are not using SAP’s full potential. For example, staff in some departments, labs, and centers are still rekeying data and creating their own spreadsheets for financial reporting rather than using SAP reports or those in the Data Warehouse. A goal of the ongoing work of the School and Area Coordinators in Financial Systems Services is to assist the DLCs in utilizing the new tools effectively. In addition, the Data Warehouse must be able to provide both the data and the kinds of reports that DLCs need. Work to achieve this is underway, and community members can contact Scott Thorne or Gillian Emmons to learn more about the Warehouse or to discuss their reporting needs.
MIT’s current procedures for reconciling accounts need to be simplified, and a pilot project to test an easier and faster reconciliation process has begun.
Centrally, we need to bring up other modules of SAP, such as the HR-Payroll system, once we have a clear understanding of our needs. A discovery team has begun work on this project. (However, as I mentioned in my April 1999 Faculty Newsletter article, the Administrative Systems and Policies Coordinating Council will ensure that the timing of projects like this one will be carefully considered.)
And, everyone in the community needs to know that periodic upgrades of software will be part of the normal course of business at MIT.
Now that the new Vice President for Human Resources has joined MIT, more of the recommendations from the Human Resource Practices Development team could be put in place.
Changes in the future may not be as radical as the cultural upheaval we experienced during Reengineering, but there’s certainly a need to continue improving how we do administrative work and to systematically measure the results of the changes we make.
|
|
|
|
|
|
|