A. Team Profile
B. Discussion of one-to-one mapping and possible ways to facilitate
experimentation
C. Information to be Collected by the Wave Coordinator During
Roll-out
D. EERA Description
E. Information Hierarchies
F. Journal Voucher Detail
G. Interviewees
H. Technology Issues
The Financial Management Implementation Team was convened on July 10, 1996 for a 12-week period. Careful consideration was given to the composition of the team drawing from Institute resources in varied departmental and central capacities. It was hoped that this broad representation would allow us to fully discuss all issues with both a departmental and central perspective. (Refer to Appendix A for a list of team participants.) The Financial Management Implementation Team was asked to analyze a series of processes relating to how we manage the finances of the Institute. The particular processes that the team focused on were creating an account (including all types of funding sources), processing journal vouchers, and processing cash. The team broke into three smaller sub-groups to analyze these processes and make recommendations. This report summarizes our findings. The work of the Create An Account Team identified a number of pervasive financial management challenges which are described in Section II.
In the course of our discussions we identified several overriding financial issues which, we believe, greatly delay our ability to achieve the MR/FO vision of re-engineering.
We must develop opportunities to establish new "cost collectors" during Release 2 while maintaining the one-to-one mapping.
The requirement for one-to-one mapping generally means that a DLC will not be able to create new accounts (internal orders, cost centers, and projects) or object codes (cost elements) in SAP without having a corresponding account or object code in the legacy system. Complicating this issue is the shortage of existing available accounts in the currently established legacy system ranges and our inability to break these ranges due to higher level reporting and the indirect cost rate calculation.
Despite the one-to-one mapping requirement, many DLCs have expressed interest in "experimentation" during Release 2, i.e., creating new internal orders or cost centers in SAP. One way to permit this would be to set up a corresponding account in the legacy system, providing that one is available in the DLC's range. There is also the possibility of creating internal orders in SAP without having the one-to-one mapping as long as the internal orders created settle to an existing account that does have the one-to-one mapping. However, any internal orders created in this way would not be able to collect costs directly from the feeder systems.
Recommendation:
We recommend that the DLCs pursue all opportunities to improve the level of management information within the SAP environment during Release 2. In order to do this, we believe it is critical that the DLCs be able to establish new cost collectors.
See Appendix B for a complete discussion of one-to-one mapping and possible ways to facilitate experimentation.
While we are optimistic about the experimentation discussed above, it must not infringe on the integrity of the books and records of the Institute. The desire for increased functionality during Release 2 must be tempered with the reality of external financial reporting requirements as well as government reimbursement regulations.
Since Release 2 will take place in several waves over the course of Fiscal Year 97 there are some concerns over the integrity of the books and records of the Institute for this reporting year. The more experimentation we do during Release 2, the greater the concern should be.
Recommendation:
We recommend that the DLCs' experimentation be documented and understood by a designated member of the MR/FO team. This designee must have the expertise necessary to assess how the proposed Release 2 changes in each DLC will impact the Institute's external reporting requirements as well as the indirect cost rate calculation.
With the exception of the "experimentation" described above, very little will change for DLCs during Release 2 roll-out in terms of basic financial architecture. Thus, the information management needs of the DLCs need to be incorporated into plans for the next phase of SAP roll-out. To accomplish this, the specific needs of departments should be defined and strategies formulated to address their needs.
For example, some departments may need greater granularity within certain functional expense categories than the current object code structure can accommodate. Others may need to see information about activities that cross organizational or responsibility lines, such as the Provost's Initiatives on the Environment, Education, International, and Industrial Relationships. Until these types of needs can be met, we believe that many DLCs will continue to need their shadow or complimentary systems.
Recommendation:
Since the financial architecture will be able to change as soon as the one-to-one mapping can be broken, we recommend that DLCs and the MR/FO team plan for this during Release 2. As part of roll-out, the wave coordinator (or some designee) should work closely with the AO or FO to assess the needs of the DLC in regards to management reporting and basic financial architecture. The wave coordinator needs to make sure that this DLC AO understands which functionality will be available during Release 2 versus Release 3.
See Appendix C for proposed information to be collected.
The CAO document entitled, "Understanding and Reconciling Monthly Statements and Detail Transaction Reports" is the basis for the lengthy reconciliation process currently required of DLCs. The breadth and depth of work required to change the Institute's policy on this reconciliation process should not be underestimated.
The process for reconciliation will begin to change by virtue of the integrated nature of SAP. Information originating in SAP, such as requisitions and purchase orders, will not have the same reconciliation requirements as transactions occurring outside of SAP. Activity originating from feeder systems will still be required to be reconciled until a detailed analysis is performed to determine the necessity of the reconciliation for each type of transaction hitting the monthly statements.
Recommendation:
We recommend that a team be developed to review the entire policy of reconciliation. This is key to recognizing man-hour savings throughout the Institute and supports the original Reengineering vision. The team should also be charged with determining a transition plan to amend the reconciliation requirements as we proceed toward the end state vision.
Certain processes now performed at the central administration levels (e.g., establishment and release of accounts) need to be assessed and wherever possible decentralized to DLCs. This will take advantage of SAP's capabilities and will eventually result in a more efficient and cost-effective process. We do not expect that all work associated with creating accounts will be decentralized. Certain types of expertise are sufficiently complex and not easily or efficiently transferable, such as costing sheets, government regulatory information, etc.
On-line tools, such as decision tables to identify the type of account to create under certain circumstances or to assign an appropriate overhead rate to a newly established account should be developed to facilitate the decentralization of processes out to the departments.
Recommendation:
We recommend the development of the concept of an "EERA". An EERA is an individual from a DLC who has been authorized to perform important financial duties. These duties would include, but not be limited to, the setting up and releasing of accounts and the processing of journal vouchers. Due to the significant human resource implications, we recommend that the EERA concept be brought to the attention of the Human Resource Re-Design Team for review and evaluation.
See Appendix D for a detailed description of the EERA concept.
As mentioned in the section on one-to-one mapping, the conversion to SAP will give DLCs the opportunity to restructure the way they keep their books to be more in line with the way they operate their business. This will bring along new challenges in that:
1. There is an inconsistent level of accounting knowledge throughout MIT -- this contributes to diverse accounting practices throughout the departments, labs, and centers which can lead to inconsistency in the summarization of data Institute-wide.
2. SAP uses very different terminology. For some period of time, we may be challenged with mastery of SAP terminology, re-engineered business processes, and the business unit needs.
Recommendation:
We suggest that an individual with a strong accounting background collaborate with administrative officers to evaluate current accounting practices in the departments as SAP is rolled out to the community. This individual would provide assistance and support for the departments during transition and help with the details of our reengineering principles and directives. In addition, this individual could clarify pertinent accounting theory as to how each unit's financial records relate to the high level Institute financial records. This is a tremendous opportunity to refine and standardize practices and procedures across the Institute and develop accounting knowledge throughout the departments.
We further recommend that those individuals who are serving in management positions in the DLCs, the central financial offices, and the management reporting staff share the responsibility for enhancing and facilitating communication. The more those in management roles participate in enhancing communications that are timely and targeted to the needs of each other, the more likely we will continue to develop an effective COLLECTIVE financial management organization at MIT.
Two opposing views were discussed within the team. The views differ in whether access to information is on a need to know basis or on an open information basis.
The ability to view detailed budgets and expenditure line items of areas outside an individual's responsibility posed several major concerns for department representatives on our team. These concerns include, but are not limited to the following:
1. Information regarding budgets or actual expenditures could be viewed out of context of the originating group, and could lead to use of information in inappropriate or non-productive ways;
2. Confidential salary information could be determined in areas where only one faculty/staff/support salary was charged to an account; and
3. Contract labor through purchase orders would be visible and could lead to inappropriate salary comparisons.
The complexity of the Need-to-know view of authorizations can be described in a three dimensional diagram with the following axises:
Users vary in their level of authorization:
To Perform Transactions: This is the type of transaction that is occurring and includes as categories: internal requisitions, external requisitions, request for payments, travel vouchers, journal vouchers, and budget and expenditure inquiries.
To review information about these transactions, referred to as Tasks: Tasks include the ability to create, route, approve, and view that which can be performed on the transactions described above.
And to execute or release transactions or information based on Limits: Limits can be determined based on dollar thresholds, account numbers, or departments.
An individual's authority to perform any activity is represented by the intersection of the three parameters (i.e., a small cube within the large cube).We believe that there is potential for consolidating the numerous combinations of authority levels into three options. Option One would consist of the least amount of cubes, while Option Three would consist of all the relevant cubes.
Confidentiality and privacy of data are cultural qualities of the Institute. While SAP technology has encouraged us to critically evaluate data ownership and access issues, it should not be the determining factor in any decision made.
Recommendation:
We recommend that the authorization issues be raised to Academic Council for a decision.
The Create An Account team spent considerable effort discussing the Information Hierarchy at the Institute and the issues of satisfying high level information needs as well as those at the department level. It is recognized that there are a series of core "dimensions" of financial information that must be maintained consistently across the Institute. There are other needs that must become more granular at a school level and yet more detailed to support the operational efforts of departments within schools and other administrative units. As this hierarchy unfolds at the lower levels, care must be given to ensure the proper rollup into the higher levels for accurate Institute reporting.
See Appendix E for proposed Information Hierarchies.
Currently all journal vouchers are reviewed by a central office. We discussed the goal of decentralizing the journal voucher process to allow departments to create and post entries with several people in the central offices. Concerns were raised over this proposed decentralization due to the complexity of certain types of journal vouchers. These concerns are summarized in Appendix F. While we recognize these concerns, we believe that the hand-offs currently required do not always add value and could be eliminated with appropriate compensating controls.
Recommendation:
We recommend that the journal voucher process be decentralized to the maximum extent possible, enabling departments to process their own journal vouchers without the need for approval from CAO and other central departments. The ability to proceed with this decen-tralization is dependent on many factors, some of which are un-resolved at this time. These factors are fully discussed in Appendix F.
Due to the limits of an entry description field to 60 characters, a decision was made by MR/FO team management to delay the processing of journal vouchers in SAP until an upgraded version of the software is available. The anticipated release of the upgrade is December 1996, which would make the processing of journal vouchers in SAP available to MIT sometime in the beginning of 1997.
Recommendation:
We recommend that the DLCs involved in the pilot be able to process journal vouchers in SAP in a controlled setting.
The team found the overall process of handling cash to be unchanged from the legacy system to SAP R/3.
Checks received directly by DLCs are sometimes retained for several days before they are deposited in the bank. Checks and cash can be deposited either at the Cashier's Office or at Baybank. In either case, paper documentation is retained by the both the DLC and the Cashier's Office and reconciled with statements. Additionally, in some cases checks must first be routed to another department such as the Treasurer's office or the Bursar's office before depositing.
Unidentifiable checks, though infrequent, require significant time and effort to analyze and can result in donor relations difficulties.
Recommendation:
We recommend that a comprehensive cash management study be performed. We feel that such a study would identify significant opportunities for cost savings.
Unidentifiable wire transfers result in notable time spent on analysis and identification.
Recommendation:
The team recommends that DLCs inform Accounts Receivable of expected wire transfers before they are received. Additionally, detailed wire transfer instructions should be developed in several languages to give to donors and sponsors.
The Accounts Receivable function in SAP is currently being used by five departments:
There is a high volume of low-dollar receivables being tracked and collected with this system.
Recommendation:
We recommend a detailed evaluation of all accounts receivable to identify areas where cost to process exceed revenues. Limits should be established to eliminate the processing of low dollar receivables. The MIT Card should be considered for employee and student small dollar amounts such as medical deductibles and library fines. Furthermore, the use of credit cards should be encouraged where appropriate.
There are also many departments that conduct their own accounts receivable with the use of shadow systems. These systems are independent of the general ledger and thus the receivables are not recorded in the books and records of the Institute.
Recommendation:
As part of roll-out, we recommend that each DLC's accounts receivable function be evaluated to determine whether SAP will meet their needs. We further recommend that high-volume, small dollar receivables be evaluated as mentioned above.
We spent some time reviewing the create account master document with an eye toward raising specific technology issues which may facilitate our ability to implement these recommendations. In that all of these issues are highly technical in nature, we make reference to them here, and include the detail in the Appendix H.
Nancy Dykstra
Assistant to the Vice President of Finance and Treasurer
Management Reporting/ Financial Operations
Elizabeth Ogar
Director, Finance & Administration
Resource Development
Donna Behmer
Senior Associate Dean, Finance & Administration
Sloan School of Management
Peter Cummings
Business Manager
Campus Activities Complex
Sharon Francis
Assistant to the Vice President of Finance and Treasurer
Management Reporting Financial Operations
Mary Grenham
Administrative Officer
Linguistics & Philosophy
William Irving
Audit Manager
Audit Division
Shyamal Jajodia (Configurer)
Management Reporting/Financial Operations
David Lloyd
CSC Consulting
Management Reporting/Financial Operations
Thomas Mullins
Director, Finance and Administration
Information Systems
Alison Salie
Fiscal Officer
Biology
Brian Tavares
Fiscal Officer
Materials Science & Engineering and Chemical Engineering
A roadblock to enhanced functionality throughout Release 2 rollout is the need to maintain the one-to-one mapping of SAP accounts to accounts in the legacy system. This one-to-one mapping cannot be broken until the following three conditions are met:
Until these three conditions have been met, constraints over the establishment of new cost collectors in SAP are as follows:
Despite the constraints of one-to-one mapping, we believe that we should maximize opportunities to establish new cost collectors during Release 2. We should explore the possibility of establishing SAP accounts that roll up to a legacy system "classic" account number:
For example, a new internal order could be established in SAP that captures purchases outside of the feeder systems. Activity from the internal order would be "settled" to a classic legacy account in order to ensure consistency of data between the two systems. A department employing this option would be able to generate financial information at the level of detail of the internal order only from SAP. Within the legacy system, the data would be commingled with other transactions of the classic legacy account.
By experimenting in ways such as that discussed above, we will gain experience in using SAP to meet departmental needs that are currently being met only with shadow systems. Until we work on issues such as this, we should not expect to be able to reduce the number of shadow systems in use by the DLCs today.
Proposed Information for the Wave Coordinator to Collect During Release 2 In Order to Provide Increased Functionality During Release 3.
The Wave Coordinator should work with the DCL representative to identify the needs of the DLC that are currently being met by shadow systems. By doing this, the Wave Coordinator should be able to identify the following:
The MR/FO team will need to provide the accounting and systems expertise necessary to the DLC so that together the team can determine the best way to meet their management information needs. As in the case of the experimentation during Release 2, the impact of the proposed Release 3 changes on external financial reporting requirements, as well as the indirect cost rate calculation, need to be assessed in each individual case. Furthermore, this information needs to be centrally collected for all DLCs in order to get a complete picture of the overall MIT chart of account revisions to be made.
For example, although we will be collecting the information necessary to revise the object codes during Release 2, this should not be done mid-year, department by department.
It is our recommendation that we begin to decentralize the release of accounts as soon as it is reasonable to do so. In this spirit, we have developed the concept of an "EERA", which is a individual from a department/school/lab/central office who has authorization to set up accounts and release them. It is based on the premise that we organize our work around the work we do (our line of business) rather than (or in addition to) the function we perform. We have conceptualized an EERA as an individual who has demonstrated the following qualities/attributes:
By definition, this group would need to be of a reasonably small size in order to ensure consistency of information. We expect that through our experimentation, we will find that it is not necessary to limit this functionality to three offices (budget, treasurer, and sponsored programs) as is done today.
It is believed that there are a set of "informal" EERAs already operating in this manner today. For these individuals, the role that the central offices play in releasing accounts is akin to "rubber stamping" the requests that come through. However, we also recognize that this change is not relevant for all accounts. There are some complex accounts that are best set up through a combination of knowledge that is both local and central.
We do not expect that all of the work associated with creating accounts will be decentralized. (Certain types of expertise are sufficiently complex and not easily or efficiently transferable (such as costing sheets , government regulatory information). We might experiment with asking local staff to enter this information as a subset of the initial "account set up". This might be guided by a set of decision rules or defaults. There should continue to be a "system/process" in place so that, within a short period of time, such complex issues/information/classifications will be reviewed/modified, as appropriate, by the professional staff within the central offices.
In short, certain types of accounts may be easier to decentralize than others. We need to better understand the operational issues as well as the technology issues associated with such decentralization. We would propose that we test this concept with some level of experimentation during FY97, while working through some of the technology and human resource issues that may be raised by the change in organizational responsibility that we are recommending.
Based on the premise that some accounts may be released on a decentralized basis, and/or routed to the professional staff of the central offices, we have outlined a set of financial requirements for creating accounts. This concept of decentralization of "release" was also being explored in the journal voucher subgroup. A set of technology issues associated with that effort will be appended. One example of the system requirements from this group might be the ability to route some journal vouchers, while having the ability to have an EERA post others. Is this technically possible in SAP? Can it be dependent on the user ID? The account type?
We also hope that the "training" scheduled for a department will reflect not only HOW the technology works, but also the APPLICATION of the technology for the business unit. Time needs to be allocated to allow a unit to understand the functionality in SAP, and how it might integrate into their business both before and while they are "going live".
OSP relies on CAO to review entries affecting research accounts for appropriateness as discussed above. In order to remove this level of review, compensating controls would need to be established. This may be difficult to do and thus Sponsored Research may be the one area where the review of journal vouchers by Central is warranted.
The Travel Office's main concern was the possibility of journal vouchers being processed using object code 953, Travel Advance. All advances must be cleared using the Travel System because it feeds into the G/L. If vouchers using this object code are done outside the system the G/L doesn't balance.
The Property Office conducts a reconciliation of all property and buildings on a regular basis. The property database is reviewed against the G/L. It is imperative that this information be maintained accurately and be auditable. Their system is a key component in providing documentation for the submission of the Institute's Indirect Cost Proposal. The Property Office is concerned that there will be more time spent correcting erroneous entries to obtain this degree of accuracy than there would be if they were reviewing transactions prior to posting.
The concern here is mostly in the area of timing. Due to the need to finalize the deficit, it is important to know that all activity has been posted and there will be no late surprises which affect deficit related accounts. Since with SAP there will be on-line real time access to transactions, the budget office will have the ability to review the result of entries without the need to hold up the posting process.
The ability to proceed with the decentralization of journal vouchers is dependent on many factors:
Treasurer's Office:
Bonny Kellerman, Recording Secretary
Office of the Vice President for Finance and Treasurer:
Jim Morgan, Consultant
CAO:
Paul Arsenault, Assistant to the Comptroller
Cheryl Botelho, Staff Accountant
Larry Connelly, Assistant Comptroller
Patricia Gilardi, Senior Analyst Programmer
Paul Honiker, Manager of Administrative Services
Demetri Karageorge, Senior Accounting Officer
Nancy Langton, Senior Accounting Officer
Jack Sears, Associate Comptroller
Guy Spina, Senior Accounting Officer
Maria Tantoulos, Senior Staff Accountant
Carol Van Aken, Assistant Comptroller
Office of Budget & Financial Planning:
John Cunningham, Budget Officer
Debbie Fairchild, Assistant Director of Finance
Robert Slauzis, Budget Officer
Office of Sponsored Programs:
Tom Duff, Associate Director of Office of Sponsored Programs
Patricia Greer, Associate Director of Office of Sponsored Programs
Julie Norris, Director of Office of Sponsored Programs
Property Office:
John Larkin, Property Auditor
Al Martingnetti, Administrative Assistant
Terry Meehan, Director of the Property Office
Kevin Milligan, Assistant Director of the Property Office
Travel Office:
Jim Enos, Supervisor
Ellen Sico, Assistant Accounting Officer
Management Reporting/Financial Operations:
Linda Scatamacchia
1. We hope that data entry of financial information about an account can be a separate process from "releasing" an account. Releasing an account is defined as authorizing transactions to be posted to the account.
Technology: can account information be entered and routed to the "authorized release agent"/EERA?
Example: A new general account is requested to collect information about a particular type of expenditure (curriculum materials). The information about the account (including information about parent/child relationships) might be entered into the system and routed for release.
2. We hope that different routing mechanisms may be set up for cost centers versus internal orders versus projects in order to release accounts.
Technology : can SAP create different routing mechanisms distinguished by who is doing the data entry? and/or by what type of account (CCI/O, WBS) is being requested?
Example: a new general account may be routed to an AO to the dean's office, and subsequently to the budget office. a new research account may be routed directly to OSP.
Additionally, a request submitted by person XXX with little know financial background would be routed to a financial officer before being routed to the individuals noted above. The routing would be triggered by the user ID
3. We hope to decentralize the set up for cost centers by controlling to a maximum dollar budget for the parent.
Technology: can SAP check child cost center budgets against parent cost center budgets when setting up accounts with a dollar budget authorization?
Example : Total budget for general account is 100K. Two children are requested, one with a budget of 50K, the other with a budget of 60K. Will the system detect the overallocation and prohibit the establishment of the accounts with those budget amounts?
Technology: can sap check child actual expenditures against parent budget dollars and/or child budget dollars when performing the fund availability function?
Example : If a transaction valued at 75K is entered in child account A (with 50K budget) will the system respond to the budget amount in the parent? the child? either (depending upon account set up?)
Technology: Does this functionality differ across CC, I/O, WBS's in SAP?
4. We hope to re-utilize SAP fields that are not necessary for MIT's configuration.
Technology: Can we change the SAP field names to something more MIT meaningful?
Example: SAP field "post office box" might be better used as an account classification field (professorship, fellowships, etc)
5. We hope to re-utilize SAP fields which appear to have been used for the initial conversion, but may not be necessary on an ongoing basis during FY97.
Technology example: Can we use the legacy system "EB ON" which is mapped to SAP field "Name 3rd line" for some other account information classification? This is relevant potentially to fields 7-13 in the financial architecture document.
6. We hope to allow for the creation of more accounts while still maintaining the one-to-one mapping.
Technology: are we breaking account ranges in order to do some experimentation?
Example: in order to experiment with the concept of lower level cost collectors, a group may want to split an existing account into 10 "lines of activity". However, they may currently be "out of accounts" within their normal range.
7. We want to allow for flexibility in compiling financial information that is not Institutionally mandatory/required.
Technology: Are some SAP account fields mandatory, while others optional?
Example: A field to designate the responsible party may be mandatory, however a field to designate the account type (instruction vs. other) may be optional.
8. We would like to continue the practice of differentiating the authorized spending level/type of transaction by user.
Technology: are there authorization assignments in SAP?
Example: user a can spend 500 at graphic arts, but not be able to approve external vendor requests. user b in the same group can do everything noted above, and also access three other accounts within the group.
9. We would like EERA's to have the ability to authorize varying levels of authorization to multiple people, rather than have this centrally administered/maintained.
Technology: Does the technology exist to support this?
Is this organizationally an issue?
10. We would like to automate as much account information as possible.
Technology: can certain account fields be system defaults which are mapped/linked and dependent upon the specific entries of other fields? If this is possible, can some fields be optionally overwritten?
Example: if the user id is in chemistry, can the system assign the school field as science?
[Chart not available in HTML]