Submitted by: Christopher Mead, Director, Department of Information Technology

Office of the City Manager INFORMATION CALENDAR March 21, 2006 To: From: Honorable Mayor and Members of the City Council Phil Kamlarz, City Manager Submitted by: Christopher Mead, Director, Department of Information Technology Subject: Update: Implementation of FUND$ Change Management Audit Recommendations (CF 27-05) SUMMARY In response to a request by the Director of Information Technology (IT) and the City Manager, in FY03 the City Auditor conducted an Information Systems FUND$ Change Management Audit. The purpose of the audit was to determine whether program change controls over the City s financial system, FUND$, were adequate and if programming best practices were being observed. The Audit findings and recommendations were presented to Council on May 4, 2004 and a progress report was presented to Council on December 14, 2004 (CF 69-04) and June 28, 2005 (CF 27-05). In the intervening time, the Department of Information Technology has made significant progress in implementing the audit recommendations. Out of the 23 recommendations, 9 are implemented, 6 partially implemented, and 8 not implemented. This update is meant to keep Council informed of our progress. CURRENT SITUATION AND ITS EFFECTS The following reports on progress regarding each audit finding. BACKGROUND The Department of Information Technology is responsible for maintaining and supporting the City s financial system, commonly known as FUND$. The May 4, 2004 audit raises many valid points regarding formalized methods, software maintenance record keeping and management participation in decisions to modify existing software or create new software. The Department of Information Technology has conducted a thorough review of existing practices, carefully considered the audit recommendations and taken a pragmatic approach to implementing more formalized methods that will reduce the City s exposure to damage due to either inadvertent or malicious software failure. In addition, all requests for software development, acquisition or enhancement are carefully considered in context to the return on investment and the organizational needs of the City. 2180 Milvia Street, Berkeley, CA 94704 Tel: (510) 981-7000 TDD: (510) 981-6903 Fax: (510) 981-7099 E-Mail: manager@ci.berkeley.ca.us Website: http://www.ci.berkeley.ca.us/manager

Update: Implementation of FUND$ INFORMATION CALENDAR Change Management Audit Recommendations March 21, 2006 POSSIBLE FUTURE ACTION The Department of Information Technology continues to refine its software maintenance procedures and to pursue the acquisition of software to facilitate and enforce those policies. Another progress report will be delivered to Council no later than February 13, 2007. FISCAL IMPACTS OF POSSIBLE FUTURE ACTION The current estimate for obtaining change management software is $15,000 - $25,000 (General Fund) for the initial purchase and a recurring software support cost of $1,500 - $2,500. If additional staff is added to facilitate the division of duties recommended, an additional $162,000 - $202,000 per year will be required. CONTACT PERSON Keith Skinner, Supervising Systems Analyst, Department of Information Technology 981-6551. Attachments: 1: Implementation of FUND$ Change Management Audit Recommendations March 21, 2006 Page 2

Implementation of FUND$ Change Management Audit Recommendations March 21, 2006 Finding 1: No formal written policies and procedures for implementing program changes to FUND$. Recommendation 1: 1.0 Develop formal written policies and procedures for implementing program changes to FUND$. The procedures should cover the processes of approving change requests, implementing a test and production environment, user testing, documenting results, reviewing results, migrating changes, and handling emergencies. 1.0 Partially implemented. A new version of the DoIT Service Request system is currently in beta testing and incorporates, among other things, a change control approval and tracking mechanism. This new version will be put in production by April 30, 2006. During the most recent HTE upgrade (Oct. 2005), test plan templates were distributed to all module leaders along with instructions for the types of tests to perform. Finding 2: Lack of segregation of functions and duties. Recommendation 2: 2.1 A programmer who modifies programs should not have access to production files and data. This is a preventive measure to mitigate the risk of unauthorized modifications that threaten application and data integrity. IT should develop a long-term plan to expand resources in the Application Development Division by either adding staff, implementing a policy of job rotation, or cross training to segregate incompatible functions as well as to reduce reliance on one single individual for performing critical tasks in the change process. 2.2 Access to production by the programmers should be restricted and subject to supervisory review and approval. 2.3 Require programmers to log and document program changes using a standardized format to facilitate ease of review and monitoring by the manager. When managerial review cannot be performed, peer review among the programmers should be in place. The bottom line is that all program changes should be subject to some form of review. 2.4 Consider installing a change control software package to facilitate the change process and to reduce reliance on human efforts. Page 1

2.1 to 2.4 Not Implemented. IT will be including a request for funding of a change controls system in their FY2006-2007 budget. Properly implementing this class of software should address all the risks identified in Recommendation 2 above. Once funding is secured, it is anticipated that the software will be selected and implemented by January 2007. Finding 3: Inadequate controls over H.T.E. s remote access to FUND$. Recommendation 3: 3.1 Change H.T.E. account passwords at least every three months. 3.2 Periodically review the access log. Work with H.T.E. to ensure that information reflected on the access log is accurate and complete. 3.3 Develop and formalize procedures to improve controls over vendor remote access. The procedures should provide an auditable and internally controlled method of granting access to the vendor and monitoring vendor activities. 3.4 Consider requiring City staff to notify Finance and IT and to explain the problems needing support prior to contacting H.T.E. 3.5 IT should consider negotiating with H.T.E. to restrict H.T.E. s access to the test machine. IT should also consider limiting H.T.E. s access to the production machine to emergencies only. 3.1 Implemented March 2004. 3.2 Implemented August 2004. 3.3 Not implemented. The change control software mentioned in the response to Recommendation 2, above, will also provide the ability to better monitor HTE activity. The software will log all changes made to software and, optionally, can be configured to disallow changes unless specifically approved by IT. The software, assuming funding is secured, will be implemented by January 2007. 3.4 Implemented Sept 2005. This matter was discussed at the last two module leader meetings and both IT and Finance will continue to reinforce the importance of this notification. 3.5 Not implemented. The proposed change management software mentioned in Recommendations 2 and 3 above would help to address this issue by providing an audit trail that could be reviewed by IT at any time. The recommendation that HTE be confined only to the test environment is not practical. It would seriously impact service delivery, particularly to critical functions such as payroll and general ledger processing. Page 2

Finding 4: Not all FUND$ related service requests are formally logged or documented. Recommendation 4: 4.1 Since the service request tracking system provides a consistent mechanism for tracking service requests, the Application Development Division should require departments to enter all FUND$ service requests in the system. The electronic service request should serve as a base document for user initiated program changes requiring in-house support. No user initiated program change should be implemented without an authorized service request. 4.2 Consider enhancing the service request tracking system so that it can be accessed directly and used by management in IT and Finance to manage and to analyze FUND$ related requests or problems. 4.3 Management should analyze patterns in end user complaints and requests and discuss them with the vendor on a regular basis. 4.1 Partially implemented. A project request component has been added to the DoIT service request system but the full approval and tracking functionality has yet to be added. As mentioned in the response to Recommendation 1, this will be implemented by April 30, 2006. 4.2 Partially implemented. All users in all departments will be able to view all service requests for their department with the new version of the service request system. IT will provide Finance with a report of all open and pending service requests for all departments at the monthly IT/Finance meeting. This will be implemented along with the new version of the service request system on April 30, 2006. 4.3 Implemented. IT has taken the lead in coordinating user enhancement requests, coordinating group training and alerting all module leaders to important HTE announcements. In addition, IT management has a monthly conference call with the HTE Director of Customer Support to discuss difficult issues that have not been resolved. Finding 5: FUND$ modules continue to not have module leaders. Recommendation 5: 5.1 The City Manager, Human Resources, Finance and IT together should perform a final review of the A.R. on Application Experts. Once the review is completed, the updated A.R. should be issued and distributed to City staff. 5.2 Direct the user department directors to officially designate a qualified Application Expert for each FUND$ module. 5.3 Direct the Application Experts to coordinate with the users to develop a screen operation manual for each FUND$ module. The responsible Application Expert should also update the manual regularly as changes occur. The manual will serve as a Page 3

quick reference for the day-to-day module operation. In addition, the process of compiling a manual will help the module leaders become familiar with the FUND$ modules to which they are assigned. 5.4 When substantial technical changes are made to FUND$, IT should provide application experts with appropriate training as needed. 5.1 Partially implemented. IT, Finance and HR are still working out the policy issues associated with the implementation of the A.R. The new target date for implementation is December 31, 2006. 5.2 Not implemented. The memo to the department directors will be issued, as soon as the Application Expert A.R. has been issued, by December, 2006. 5.3 Implemented Sept. 2005. IT meets with the Application Experts on a quarterly basis and has encouraged them to document their process fully. In addition, IT has provided several resources, such as templates, to help the Application Experts with that task. 5.4 Implemented Sept. 2005. IT provides Application Experts with extensive information about the upgrade, analyses by the programming staff regarding changes and how they affect each module and self-paced training presentations that cover all new changes. In addition, IT coordinated a number of training sessions offered by HTE to make users aware of changes in the last upgrade. Finally, IT has prepared and coordinated users for attending the regional and national user conferences which thoroughly cover planned changes to the software. Finding 6: Concerns with FUND$ version upgrade. Recommendation 6: 6.1 The Application Development Division should develop an action plan that clearly defines the methodology for implementing software upgrades. The plan should lay out critical deadlines and available resources that are needed during an upgrade. Conflicts that cannot be resolved by the departments should be referred to the planning group for resolution. 6.2 IT should consider including in the service support agreement a provision requiring H.T.E. to provide complete documentation of their changes and to be responsible for timely correcting problems resulting from incomplete documentation. 6.3 IT should reduce the number of custom programs by eliminating programs that are obsolete or not used. 6.4 Since recurring costs and efforts are required to maintain custom programs, a cost and benefit justification should be required for all program change requests submitted by user departments. When a reasonable justification cannot be provided, IT should retain the right to deny the request. Page 4

6.1 Implemented. IT had formalized the procedures for implementing software upgrades. Testing and training templates were developed by IT for the Application Experts and will be distributed to them when they are appointed following the publication of the Application Experts AR see 5.2. 6.2 Not implemented. IT agrees with the finding and recommendation. IT will discuss this option with H.T.E. when the next service support agreement is executed in 2007. 6.3 Implemented. Eliminating customized programs is now a standard part of the upgrade process. All modifications are reviewed to determine when they were last used. Anything that has not been used for two years or more is archived and retired. IT also carefully reviews all new features of the upgrade to determine if they supercede modifications done by COB. 6.4 Partially implemented. IT carefully reviews each request and evaluates the impact of each on our overall system support workload. This approval process will be formalized in the online request system (DoIT) by April 30, 2006 Finding 7: Project management methodology and IT governance are not formalized. Recommendation 7: 7.1 An executive policy group should be formed to align IT resources with the City s mission, strategies, and priorities. The City Manager should delegate to the executive policy group the authority to recommend to the City Manager, on behalf of the Deputy City Manager and department directors, how IT resources should be allocated. This group should be convened and staffed by the City Manager. Other sub-committees, established to deal with specific system issues or needs, could include the existing Financial Software Policy Committee s current charge governing major new financial application deployment. The sub-committees should report in writing to the governance group. These groups should actively work on ongoing improvements to the City s systems and technical issues, including training needs. 7.2 The draft IT Master Plan should undergo a thorough review process by the appropriate group. After recommended changes have been considered and incorporated, as appropriate, the IT Master Plan should undergo final review and approval by the City s policy group and the City Manager. 7.1 Implemented. The Technology Governance Group meets every 2 weeks and has been reviewing and prioritizing major IT projects and IT policies. 7.2 Partially Implemented. The Master Plan will be submitted to the City Manager for review. IT will revise the plan to reflect changes in technology and the needs of the City, in cooperation with the Technology Governance Group, on an annual basis. The next update will be prepared by December 2006. Page 5