Veronese & Tiffany Inc. is a medium-sized business located in Elmira, Ontario. It sells designer jewelry to specialty stores through Canada as well as to individuals through its company website. Founded by close friends, Veronique Veronese and Tameka Tiffany almost 10 years ago, the company has grown rapidly and now has well-established brand recognition as well as a large following of loyal customers (direct and retail) across the country. Currently, Veronese & Tiffany Inc. products are carried in more than 2,500 boutique stores and online retailers. While Veronique focuses on sourcing material and design, Tameka spends most of her time managing the sales force, strengthening relations with retailers, and marketing to the company’s online customer base. At the same time, due to lack of expertise and inclination, the owners have not spent much time investing in accounting and information systems.

 Automation of processes has been slow and ad-hoc to keep pace with the company’s growth. Two years ago, the company hired Summer Sloan as their Chief Information Officer and tasked her with building an integrated information technology framework to support the business processes as well as maintaining a strong control environment. Given the state of business processes and limited resources allocated towards information technology, progress on this front has been painstakingly slow. Veronique and Tameka are also frustrated with the lack of progress or significant benefits from their investments in this endeavor. Consequently, they have engaged you to review their current process and systems to identify weaknesses and provide recommendations. The following sections describe the key people, processes, and technologies currently in place at Veronese & Tiffany Inc. 2.2. Payroll Processing All Veronese & Tiffany Inc. employees are expected to complete a timesheet by 4 PM of Friday on a weekly basis in the timekeeping module of AviOnyx (except for the floor staff of the warehouse team). The timesheets are consolidated in AviOnyx and available to the Payroll Analyst for processing. Function managers also notify the Payroll Analyst and the Workforce Manager of all changes in employee status (new hires, transfers, promotions, terminations, temporary movements, etc.). The Payroll analyst makes necessary adjustments to employee status based on notifications received from the functional managers prior to processing payroll. The Payroll Analyst reviews the consolidated timesheets and the payroll expense assigned to various cost centers by AviOnyx for appropriateness, accuracy, and completeness. Next, the Payroll Analyst finalizes the pay disbursement order for that week. Every two weeks, the Payroll Analyst sends the consolidated funds release instructions to the Bank. The warehouse team leader is responsible for the floor staff performing all materials movement activities. Individuals performing these tasks punch in their timecards upon entering and exiting the warehouse space. On a weekly basis, the warehouse team leader reviews and approves all timecards and prepares a summary of the hours worked by his team. 

This “Hours Worked Summary Report” is submitted to the Payroll Analyst for processing. The Payroll Analyst manually enters the contents of the “Hours Worked Summary Report” into the computerized payroll system. The system updates the payroll records and prints out the paycheques. The cheques are written on the regular chequing account; imprinted by a signature plate with the treasurer’s signature; and sent to the warehouse team leader, who distribute them to the workers or hold them for absent workers to pick up later. Warehouse team leader notify data processing of new employees, terminations, changes in hourly pay rates, or any other changes affecting payroll. The workers also complete a job time ticket for each individual job they work on each day. These are collected daily and sent to cost accounting, where they are used to prepare a cost distribution analysis. The payroll function had not been operating smoothly for some time. The warehouse team leader would like a weekly report indicating worker tardiness, absenteeism, and idle time to determine the amount of productive time lost and the reasons for the lost time. The following errors and inconsistencies have been encountered the past few pay periods: 1. A worker was issued a cheque for $4,531.80 when it should have been $453.18. 2. One worker’s paycheque was not written, and this error was not detected until the paycheques were distributed by the warehouse team leader. 3. Some of the payroll register records were accidentally erased from the system when the Payroll Analyst tried to reorganize and rename the files in the hard drive. Data processing attempted to re-establish the destroyed portion from original source documents and other records. 4. One worker received a much larger paycheque than he should have. The Payroll Analyst had keyed 84 instead of 48 for hours worked. 5. Several paycheques issued were not included in the totals posted to the payroll journal entry to the general ledger accounts. This was not detected for several pay periods. 2.3. Information Technology Change Management At Veronese & Tiffany Inc., Business IT Enterprises Services (BITES) is led by its CIO to actively support the organization structure by reviewing the overall business strategy and ensuring alignment as well as by following the Executive Management direction and tone on an annual basis. The security risk environment is dynamic and ever-changing. 

To properly manage security risks, Veronese & Tiffany Inc. establishes the tolerance of security risks by conduct security risk assessments every two years to identify unacceptable risks and determine what to do about them. While a standard set of policies and procedures are currently being developed, where IT roles (i.e. Database Administrators, Infrastructure Systems Administrators) have a segregation of duties exposure (i.e. access to both non-production and production environments), it is mitigated through compensating controls (e.g. separate User IDs for database administrators operating in each environment). The set of policies currently being developed includes key topics such as Enterprise Architecture, Information Management, Infrastructure Management, Privacy, Compliance, Business Continuity and Disaster Recovery, Crisis Management, Regulatory Compliance & Reporting, and IT Risk Management. Once finalized, the policies will be stored in a secure section of the company’s intranet that is accessible by all executive management. Based on the results of the last functional security risk assessment as well as the progress made to-date on developing the set of policies and procedures, senior leadership within BITES have developed (under guidance from the CIO) the following change management process.  Standard changes: A standard change management process is followed for change tickets to add new entities (customers, vendors, collaborators, etc.) to AviOnyx. These changes are routine in nature and are pre-approved by the business users. The change ticket is initiated by a member of the Application Management Services (AMS) based on the request received from the business. The implementer will review and approve the ticket once he/she has processed and implemented the change and update the status of the ticket to “Completed”. User acceptance testing will not be required for these standard changes since these changes only involve update/change in the table which is routine and minimal risk.  Data changes: The process for data corrections follows a similar process as the standard change management process described above. A change ticket is created for the Database Management team and the information about the data correction is captured with the change ticket. After the correction, the Database Management team validates the change and closes the ticket.  Maintenance changes: Based on the decisions made during the weekly/monthly prioritization meetings between various businesses and the AMS team, the maintenance releases are scheduled. A service request ticket is created by the business support analyst (based on inputs received from the business owners) and authorizations are obtained within the request ticket. An application change request ticket is then generated by the AMS team and assigned to the developer who makes changes in the development environment. Once the changes are developed, the system testing is performed by the testers in the development environment. 

User Acceptance Testing (UAT) is then performed and approvals are provided by the end-users. Testing signoffs are retained within the associated change ticket. Upon successful completion of UAT, the Service Manager, on behalf of the functional user group signs offs in the change ticket. Once these signoffs are completed, the Technology Lead and Release Management will approve the promotion of the change to the System Integration Testing environment; where the changes are tested to see how they affect the system. The change is then approved by the Service Manager and Release Management and promoted to the Pre-production Staging environment, where deployments of the change are tested and backout procedures may be tested. Finally, the Production Control team will promote the changes to production during one of the regularly scheduled deployments. The Source Code Library Management (SCLM) contains the source code for AviOnyx, and developers have access to check out packets of code in order to make changes. The code can be checked out by the developer on their local drive for making changes and once changes are made to the code, only developers can check the code back in to be promoted to production by the production control team. If approvals described above have been completed, Production Control will promote the changes for AviOnyx.  Emergency changes: An emergency application change is required when there is an immediate and material required to address the root cause of high-severity level incidents. When responding to this incident timely restoration of the service is critical. Therefore, it is appropriate to complete the requirements of the Emergency Change Process without updating the Emergency Change ticket until after the incident is resolved. An Emergency Application Change Request is created by the Change Manager that identifies the severity of the incident being addressed as well as how the change will effectively mitigate the underlying risk and its impact. 

Next, the development, testing, and staging of the application change are completed. The Change Manager for AviOnyx validates that the application change meets the organization’s standards are met and is ready for deployment. He / She will also revisit the Emergency Application Change Request Ticket and ensure that all prerequisites have been met, and then approve the ticket. The Change ticket will be updated once the implementation is completed. Testing is conducted following the implementation to verify that the application change is delivering the desired results. The Change Manager will login into the Emergency Application Change Request Ticket and ensure that all information is attached, and the ticket is complete. After this validation is complete the ticket will be closed.  Monitoring of system and data changes: Before a change ticket can be closed, the release coordinator must complete a post-implementation interview with the business requestor, which includes filling out a checklist. However, due to a lack of sufficient resources and bandwidth, this process has not been consistently followed on changes implemented to date. While a recruiting plan exists to provide additional support to the resource coordinator, the post-implementation review has been conducted in approximately 15% of the changes implemented in the last 18 months.

Can you assist me with some ideas from the case study with regard to the payroll business process?

 

Transcribed Image Text:

Selected IT Process Process Objective Key Risks Control Objectives Key Technologies Preparer(s) Approver(s) Key Artifacts # 01 02 03 04 05 Control Objective Payroll ● ● ● ● ● Application Controls Audit Program - Business Process (Payroll Process) ● XXX Key Risk Control Activity Control Activity Attributes Audit Criteria Audit Procedures Selected IT Process Process Objective Key Risks Control Objectives Key Technologies Preparer(s) Approver(s) Key Artifacts # 01 02 03 04 05 Control Objective Payroll ● ● ● ● ● Application Controls Audit Program - Business Process (Payroll Process) ● XXX Key Risk Control Activity Control Activity Attributes Audit Criteria Audit Procedures