[Previous] [Next]
[Previous] [Next]
A variety of factors can prevent an institution from using "hot" new management tools effectively -- lack of appropriate training in how to apply the models; a resistance to change from key stakeholders of the processes being reviewed; lack of support for such study from institutional leaders; disagreements within the campus community about the necessity for change in these areas; and being overwhelmed by the jargon and exercises of the models, to the point where it is not possible to produce an effective study and report. In fact, it is better to adopt the tools of these disciplines and eschew the jargon wherever possible.
Managing all of these risks, in order to get maximum advantage from the process review, is one of the critical success factors in the business evaluation process stage of the project.
Managers within the financial units should also be involved in reviewing the work of the teams and providing clarification when necessary, although their role must not interfere with fully recording both the current practice and that which would be preferred. (See the sidebar for a suggested composition of teams that might be formed to evaluate a number of common business processes.)
While outside consultants may be useful in shaping the process by which the business analysis is performed, the resulting product must be one that is institution-specific, and thus one that is fully shaped by institutional players. Having appropriate members of the community involved in these efforts will be key -- senior managers must demonstrate ownership of the process and support for the outcome, while managers of the financial units will need to set priorities for change and provide guidance to the overall process.
Users and providers of the services, both centrally and in the core academic units, must also be involved in the analysis of the status quo and the structuring of alternative methods of doing business. The introduction of new ways of processing transactions or passing data is trivial compared to the challenge of new ways of administering the overall processes of which these transactions are a part, and the data that result. Business process redesign needs to be "customer driven," and customers are everyone involved in a process and its outcomes. In the final analysis, success for this part of the project will be driven by the functional users of the systems, not the technologists who support the systems.
Involving all these key players in the review process will result in significant success in effecting change in the institution. If the stakeholders have participated in the business process evaluation and see that the proposed changes will better enable them to be served by "the system," they will become the strongest advocates for the changes being recommended, which will move the implementation project forward more swiftly. If they do not feel that they have been consulted, or do not see that the recommended changes will make any significant improvement in reaching their goals, the implementation process will be long indeed, and possibly destined for failure.
While sometimes dealt with as part of the student system, the financial aid process may also be included in the financial business process review depending on the organizational structure and institutional culture. In addition, the physical plant area may or may not be viewed as part of the financial processes, including maintenance scheduling, work orders, and stores management and supplies inventory. Other functions that might be included are operating and/or capital budgeting and planning (increasingly important functions that need to be integrated), grants and contracts management, and inventory and fixed assets.
In determining which processes to evaluate, it is important to conduct a scan of the external environment to learn from the experiences of peer institutions that have engaged in business process reengineering. This effort is both a time-saving and stress-saving device, as well as a strategic exercise that will enable the project management team to focus quickly on areas where the process will have an optimal chance of success. This external scan will provide an opportunity to see what has worked for other institutions and businesses, and what have been pitfalls or areas of material challenge. It is also valuable to review best practices in industry to help define the state of the possible.
In addition, other broader institutional priorities outside of the financial systems project must be taken into account when defining the nature and scope of the process evaluation effort. Are there other process evaluation projects planned or ongoing in other areas of the institution, and if so, how does the financial project complement or contrast with those? As the process evaluation effort makes it possible to more closely match current institutional needs with current technological realities, an understanding of which areas are of most institutional significance will be crucial when deciding which problems to solve first and most completely.
Indeed, the strategic selection of appropriate processes for review and potential change can help to avoid another project land mine, that of focusing efforts on an area that is not important enough. It is often tempting to select a project that is viewed as "stand-alone" or "lower priority" in order to decrease the pressure for success. Unfortunately, this also decreases the interest in success and makes it harder for the resulting changes to be accepted, since they are not seen as being of significant import to the institution's overall mission. Although financial systems are often viewed as an institutional priority, that is not always true, and within the general rubric, some systems can be viewed as more significant than others. Focusing significant institutional resources -- in the form of team involvement, report generation, and so forth -- on an area that does not enjoy significant institutional focus can produce a result that is of insufficient interest to merit additional attention and support.
In a situation where several possible projects have equal importance or significance, choosing first the one with the greatest chance of success is a wise strategic move. Defining the business process targets realistically by identifying the key problems to be solved, and also those that are not going to be solved, prevents the business process evaluation effort from becoming overwhelmed by potentially competing problems. With an evaluation effort focused on too wide an area, the time between study and resolution will overtake the team's enthusiasm for being involved in such work, and all subsequent evaluations will suffer from lack of involvement due to project burnout. Keeping the analysis and results focused on key areas of the process under review both facilitates a sense of accomplishment on the part of team members and provides a useful and concrete product to be used in creating the requirements document.
Another strategy for keeping the chosen set of projects manageable in scope is to consider those areas that could be left in their current configuration, but interfaced to a new, redesigned financial process. This could require only the creation of a technological interface between a current system that will not be replaced and the newly implemented financial system, or it could mean creating a "process interface" feeding new processes that have been redesigned off of existing systems that are found to be relatively effective. The University of Delaware is successfully using this approach.
The analyses must address strategic questions about the present and the future of financial management practices at the institution. Much of the general construction of these analyses can be based on the overall analysis performed by the steering committee in setting the larger goals for the project -- the business process evaluation will build on this steering committee work by looking in greater detail at particular processes.
Institutional direction is also an important component in structuring the business evaluation effort effectively. Is there an interest in redefining administrative priorities or organizational relationships (i.e., moving from a more centralized to a more decentralized responsibility center model) or in redefining the role of financial analysis and understanding in the decision-making of the institution? There are no right or wrong answers to such questions, but the business process evaluation effort must be focused in a way that complements the future direction of the institution as a whole, as will have been reflected in the initial report of the steering committee.
Finally, it is important to balance this project against other institutional priorities; by allowing it to expand beyond reasonable bounds, the level of change introduced to the institution may overshadow any good done in these specific areas.
All members of each business process team should be involved in documenting, reviewing, and recommending changes to the current process they are evaluating. These evaluations can be managed in as formal a way as "process flow documentation" sessions, supported by outside consultants and relying on full-day retreats and deliverable documents; or they can be informal brainstorming and note-taking sessions convened over the course of a few weeks involving one or two staff from each financial processing unit (payroll, accounts payable, and so forth) -- the level of formality of this process should be driven by institutional mores, expectations, timeframes, and budgets.
Each team, however, should complete its process by being able to describe the significant "inputs" and "outputs" for the process, the tools currently being used (technology-based or otherwise), and the expected new approach as described through text, visual mapping, or a combination. This process description should include information about the planned uses for technology in this new environment, in enough detail to make the evaluation of currently available technologies possible. (See the sidebar for an example of the evaluation of the procurement/payables process at a medium-sized institution.)
A key component of this phase of the mapping process is "data mapping" or "data modeling" -- the process of articulating key data elements that must be captured, stored, and managed, the purpose and/or use of the data, and the rules for each of these functions. Including a data mapping process at this point will enable the business evaluation process to most effectively introduce changes, and will also ensure that the project meets key decision support needs for the institution.
For example, Indiana University spent 18 months doing data modeling with the departmental users before a request for proposals (RFP) was produced for its new financial system. While there was a lot of resentment at first about this potential waste of time, in the last analysis, there was almost universal agreement that it was a major factor in the ultimate success of the entire initiative. Both users and financial staff seemed to learn a great deal about how the process should work in the new system, and it made the RFP process easier and resulted in a savings from dollars that would have had to be paid to the external partner had it not been done.
It is also wise to consider the notion of metadata, i.e., data about data -- what they mean, where to find them, how to interpret them, and so forth. As distributed reporting increases, end users must be educated about what the data mean, and there will need to be a way to maintain this information so that it is readily accessible by users. Purdue University, for example, uses the World Wide Web to provide easy access to its metadata with hypertext links to diagrams, examples, and high-level and detailed definitions to support both the novice and the expert user. Document management and generation for the Web is an automated process, so it requires less maintenance.
Given the future need for this kind of information, rather than adding it as an afterthought later in the process, the business process teams can be asked to develop documents in a prescribed format during their evaluations that could then be easily incorporated into the later documentation and training materials.
This redefinition of process also must be flexible enough to be shaped by specific software solutions as they are selected. It is for this reason that the technology evaluation team and business process teams must work in tandem, with frequent sharing of information, and perhaps supplemented by strategies such as overlap in team makeup, so that this work can be completed in synch.
This process of confirming the existence of technology tools that are consistent with business process recommendations represents a critical success factor for the project. Although any process evaluation effort will have as an early stage a "blue sky" exercise that imagines the ideal world of completely revamped processes, it is important at some point in the effort to bring the recommendations back to earth.
When discussing technology tools, the project teams should be aware of the need to manage the institution's expectations about the use of those tools -- that is, to be clear about the distinction between the existence of the technology and the institution's ability to use that technology to support change. The analysis of whether that technology exists in a form that is mature enough, well-supported enough, and robust enough to be used in whichever key institutional process is being examined is a continuation of the gap analysis that was part of the steering committee's work. This analysis should be performed relatively early in the process review, so that the work to create an imagined redesign remains firmly grounded in the reality of potential technology solutions.
When the business team reports are in a representative semifinal state, they should be reviewed by the project management team to provide an opportunity for cross-team integration, and then referred back to the steering committee to ensure that the recommended changes are within the scope of that committee's institutional vision.
Particularly for processes that cut across a variety of traditional institutional boundaries, it is important for the broader institution to be kept informed of major recommendations, so that their impact on other areas of the institution can be analyzed and integrated into ongoing plans.
Of course, the extent to which process changes are deemed vital to the success of the project, and the availability of technology tools in the marketplace to support those changes, will be key factors in the decision-making about whether to buy a system, develop or migrate systems in-house, or partner with other institutions and/or vendors to build a new product jointly.
[Previous] [Next]