Organizational
Quality and
Communication Improvement (QCI)
|
Organizational
Quality and |
|
|
13 April 1999
This report contains a description of methodology, a process listing for RUCS, description of selection criteria, and final recommendations for target processes. The final recommendations do not represent a complete list for improvement, but rather a manageable subset of processes for preliminary attention.
The Process Inventory Team (PIT), which first convened in October 1998, consists of the following members:
RUCS, like all large organizations, is in a state of continuous review, but tends to apply time and resources towards dealing with existing processes instead of modifying them. The team was formally charged with generating a short list of organizational processes for review and potential improvement. It would have been a fairly trivial undertaking to quickly select a small number of processes that could be targeted for improvement. While it is possible that this would have identified a very good short list of processes, it is far more likely that the team would merely divert resources and attention to issues and concerns that had enjoyed recent, instead of systemic, relevance. This approach would have been similar to the generic RUCS approach executed across the organization on an individual level. In essence, the team would be elevating the firefighting mentality from an individual operating mode to an organizational one.
The team elected to deviate from standard operating procedures and to undertake the larger task of reviewing a more complex process listing associated with RUCS. From this larger list of processes, the team developed target criteria and selected a reduced set of matching processes. The reduced list was subsequently reviewed to identify the recommended processes to review and improve. Even in the absence of process improvement, the ability to organize and review a comprehensive organizational process listing has intrinsic value and can be utilized for future projects.
The simplest method to generate a comprehensive set of processes would be to list them directly. This approach is relatively easy, but in the absence of overlying organizational structure would suffer from excessive surface complexity. The relationship between associated processes would be obscured as there would be no clear way to distinguish between respective levels. A listing would have little value unless a basic structure could be identified to provide additional context.
In order to deliver a wide variety of services to an extremely large, distributed, and diverse community, RUCS is, by necessity, a large organization itself. The size of RUCS makes it possible to deliver the needed variety of services, but often makes it difficult for customers to locate specific resources. There is significant information available which explicitly defines the roles of the various RUCS divisions, but this information is not necessarily well organized or otherwise presented in a fashion that the customer finds accessible. The result is a fundamental disconnect between what RUCS is doing and what the university community perceives is being done. Unfortunately, for the majority of the university community, perception is reality.
The manner in which RUCS views itself could be referred to as its internal perspective. This perspective is driven by organizational boundaries, divisions of responsibility, and informal associations and collaborations. This view of RUCS is frequently confusing for new employees and is almost always confusing to the Rutgers community. It is difficult for them to understand the subtle distinctions in responsibility and reporting that are largely driven by historical operations and/or technological considerations.
Figure 1: Simplified depiction of the relationship between services, constituent processes, RUCS and the Rutgers community from a RUCS internal perspective.
The RUCS perspective of itself is primarily organizational. Essentially, services delivered by RUCS are the culmination of a series of processes that potentially span disparate segments of the organization (see Figure 1). The RUCS internal view compensates for inter-divisional handoff of responsibility and for any coordination of effort that may be required to deliver a specific service. It has never been effective to require that the Rutgers community understand the complexities of RUCS in order to obtain access to services or resolve problems.
The Rutgers community does not view RUCS from the perspective of organizational hierarchy, but rather as a collection of services (see Figure 2). In general, the external view of RUCS is dominated by the most visible services that are delivered. Services are viewed as largely independent and there is generally very little familiarity with the complex processes required to deliver these services or how these processes map onto the RUCS organization. The average customer does not know and does not care how RUCS delivers these services. It is the service itself, that the customer cares about.
Figure 2: Simplified depiction of the perceived relationship between the Rutgers community, services, and RUCS from the perspective of the Rutgers community.
While it would be helpful to encourage convergence between the internal and external perspectives of RUCS, it is not likely that the Rutgers community can be coaxed into changing their perspective. They see little value in understanding the nuances of the RUCS organization and will insist that we focus on their immediate concerns. It is the responsibility of RUCS to coordinate inter-divisional activity in order to work efficiently, but unless there is direct, visible change at the service level, improvements will be largely invisible to our customers. The team did not attempt to resolve the dichotomy between the internal and external perspectives. Instead, it was decided that the appropriate perspective for process identification was that of the customer. This is the only approach that will allow the collected information to be utilized in a fashion that will be immediately recognized by our customers. Thus, the team viewed RUCS processes from a largely external fashion. In order to organize a comprehensive process list, the following customer groups were identified:
The team consulted a variety of resources in order to generate an extensive list of processes for possible improvement. The RUCS directors provided information through their meetings and the team formally queried the RUCS associate directors. All team members utilized personal knowledge as well as second hand knowledge obtained by informal conversation between themselves and members of RUCS or the university community.
A process is defined as "a set of interrelated work activities characterized by a set of specific inputs and value-added tasks that produce a set of specific outputs for the customer." Processes were associated with larger service categories to mirror the way in which they were most frequently viewed by customers and placed in the customer group that was the immediate recipient. There were several levels of processes generated, with their corresponding relationship intended to be obvious. Level 1 processes represent the highest level and consist of level 2 sub-processes which, in turn, consist of level 3 sub-processes. The extensive process listing appears in Appendix A.
The team consulted a variety of resources in order to generate a reduced list of processes for possible improvement. The RUCS directors provided information through their meetings and the team formally queried the RUCS associate directors. In addition to this, the Customer Identification and Needs team report was consulted to obtain information regarding what the RUCS’ customers needed and/or wanted. Finally, all team members utilized personal knowledge as well as second hand knowledge obtained by informal conversation between themselves and members of the RUCS or Rutgers community.
Based on all available sources of information, the following set of filtering criteria were utilized to reduce the extensive process and service listing associated with RUCS to a manageable size:
It was believed that the overlying consideration for process identification was customer impact. As was previously stated, RUCS could markedly improve some underlying process that was entirely internal and had no direct impact on customers, but this effort would go largely unnoticed. The team also decided to cherry pick and identify processes that were largely or entirely owned by RUCS and offered potential for substantial improvement. The ability to work across divisions was viewed as important because these processes tended to impact large numbers of customers and it was clear that inter-divisional coordination is not always optimal. The following reduced list of processes satisfied the filtering criteria:
While the above were extracted from the comprehensive listing of existing processes, RUCS could also be improved by the addition of new processes and services. These do not necessarily need to be a direct response to the improvement of any existing process. The following processes and/or services were identified as potentially attractive from this perspective:
Ultimately, the recommended processes have been selected to keep customer focus as high as possible. RUCS ability to recruit and retain quality employees is viewed as a critical internal effort and hence did not fit the final criterion of direct customer impact. The following processes are all customer centric or can be viewed as directly impacting many customers:
While the recommended list is certainly more manageable than the extensive list or even the reduced list of processes, there are some obvious opportunities for coordinated effort. To be specific, the first three items listed (communication, help desk, and problem tracking) are not unrelated; they contain sufficient overlap that any effort to improve one would impact the others. The first process listed (communication) is not intended to be a generic or far reaching category. The specific modes of communication listed have been identified as suitable for attention and improvement. Finally, the absence of personnel retention from the recommended list does not imply that this process could not be improved.
One criticism of the RUCS web pages is that, while they are almost entirely organized along divisional boundaries, they are sufficiently inconsistent as to appear unrelated. There is a relative absence of the similar formatting and style queues to ensure a RUCS association as the content is viewed. There are very few indices and/or search engines and a large portion of the information available is critical path based. This requires a customer to traverse a very specific set of links to obtain the desired information. This often makes navigating the RUCS web pages difficult for the uninitiated. Locating the correct web page is not always sufficient; the overall density can also make it difficult to spot the appropriate information. Some content appears without an update reference so it can be difficult to determine if it is stale. Finally, the absence of an explicit point of contact for each page makes obtaining additional information problematic. Additional customer input and feedback could have played a larger role in the overall design and implementation of the RUCS web pages. These issues do not apply to all of the RUCS web pages, but they appear often enough to reduce their overall usefulness.
RUCS contact tends to suffer from some of the same problems that undermine the overall effectiveness of the RUCS web pages. Despite the existence of extensive contact information, most customers and employees rely on anecdotal contact lists or prior encounters which met with favorable results. This is ultimately counterproductive as the process flow associated with any specific problem is non-deterministic and potentially outside the view of any oversight and/or improvement effort. These informal processes flow along historical paths and have resulted in some exceedingly convoluted solution mechanisms that are incomprehensible to the RUCS customers.
Interdivisional communication problems directly impact customers in the establishment of project priorities. When a customer attempts to negotiate a suitable priority for any specific project and to schedule a completion date, they may be dealing with only one division of a multidivisional process. This directly undermines their ability to establish a binding priority level or even to schedule completion with any real certainty. The project is not predictable and ultimately takes too long to accomplish, but the customer finds it difficult or even impossible to obtain definitive information. Interactions between the customer and RUCS may fail to achieve positive progress during any single encounter. This can be frustrating to both the customer and RUCS.
A help desk is a critical vector for customers to gain access to the resources of a service organization. This communication role is vital as public relations are often driven by direct interaction between the organization and its customers. RUCS utilizes multiple, independent help desks which are confusing to customers, because they often contact the wrong help desk and may be bounced elsewhere. Since they are unsure which help desk to call, and cannot always discern why one question was answered and another was not, the help desks are generally viewed as inconsistent and not particularly helpful. This is not to say that any specific help desk is not fulfilling its mission. In general, each one tends to perform its tailored mission effectively, but this is not the overall perception in the Rutgers community. This would not be corrected by implementing a monolithic help desk to resolve all issues for the entire University. The University community is sufficiently diverse that there would appear to be value in a help desk in Camden, for example, that was more appropriate to the specific needs of the Camden community. However, this help desk would need to respond to all of the issues of all of the users in Camden. If the problem could not be resolved locally, it would be transferred without user intervention. Any specific user should be able to enter a coordinated RUCS help system at multiple locations and obtain the same result, regardless of internal issues of responsibility.
Ultimately, one of the primary roles of a help desk is to provide for effective problem tracking and resolution. The issues which are relevant to problem tracking, however, are not unique to a help desk. Many customer problems require effective coordination and transfer of information between responsible entities. It is critical that the customer be kept informed of this and any other details pertinent to the status of the problem. This does not imply that the customer must play a passive role in this relationship. Either the customer is provided with problem status, both on a regular basis and when significant events occur, or this information should be readily available by some other means. Consistent with the logic of help desk/customer interactions, it should be possible to effectively introduce problems for resolution at multiple entry points. This is not a recommendation that RUCS restructure to permit the entry at any point. It is unlikely that either of the two boundary conditions, one entry point or any entry point, would be appropriate. The former is too restrictive and the latter would be unmanageable. Regardless of the mechanism by which a problem is identified, it must be resolved in a timely fashion without languishing between divisions or groups during a failed handoff.
RUCS has continuously struggled with the details of account administration, resulting in significant confusion in the Rutgers community regarding the actual policies that govern account access. There are frequent problems addressing the needs of guests or any other customer not already in WhitePages. Also, the current mechanisms that allow for customers to create their own accounts suffer from load problems during peak periods at the beginning of each semester. There are a number of technical and policy issues pertaining to account deletion as well. It is not always clear to why or when they will lose a specific account. Further, there is sufficient inconsistency across multiple accounts, that users are confused about what services will be available and what restrictions apply. General account maintenance is a complete mystery to some portion of the users who do not understand how to change a username or how to monitor and manage their account quota.
Email is potentially the most important application provided by RUCS. Many customers would not require a RUCS maintained central account if they could obtain email by some other means. Unfortunately, email access and services are not uniform across the university. Email identity is tied directly to an account username which imposes significant restrictions on names. Customers are largely uneducated about their own responsibilities or how email works. The technical ability of the overwhelming majority of email customers is not sufficient to effectively manage email across multiple accounts. It is not possible to effectively support the wide variety of email readers currently in use and, in the absence of promoted standards, the Rutgers community struggles with incompatible and/or unknown formats.
In addition to the recommended list of existing processes to be targeted for improvement, the following process was selected as a potential addition:
This team believes that there is a very large portion of the Rutgers community which would be highly appreciative of some genuine guidance and leadership in this area. The majority of RUCS takes their technical familiarity for granted, but the Rutgers community finds the array of hardware and software bewildering. They want to make intelligent, economical choices, but require some assistance in order to accomplish this. If RUCS could make some modest recommendations on sensible hardware and software that would be supported, the overwhelming majority of the Rutgers community would immediately incorporate this information into the purchasing process. Less variation in hardware and software would provide potential economies of scale in both purchasing and maintenance. Further, it would be unrealistic to expect that RUCS can answer all questions of all customers in a manner which is entirely satisfactory to them. Greater commonality in hardware and software across the community would facilitate informal interaction and assistance between customers.
The Process Inventory Team has completed, in accordance with its charge, a review of RUCS processes. There have been several key results obtained from this. The first is that RUCS needs to view itself from the perspective of its customers. This is the most important view of any service organization and one that needs to have the highest priority within RUCS. The inability to refine processes and the delivery of services in a fashion that seems appropriate to its customers will relegate any improvement to the periphery and fail to achieve significant gains in the eyes of the Rutgers community. The second is the actual list of recommended processes, from which all would benefit if studied actively by a RUCS process team. The Process Inventory Team could serve as a resource for any process improvement teams that are established and provide additional information as requested. The recommended processes all have direct customer impact. This is not to say that there is no place in RUCS to improve internal processes, but this would not be an appropriate priority for a service organization striving to improve its public image.
|
Questions/comments about this website can be directed to
webmaster@nbcs.rutgers.edu.
Last updated:
Thursday, 11-Nov-2005 10:26:12 EST
©
2005
Rutgers, The State University of New Jersey. All rights reserved.