![[object Object],[object Object],[object Object],[object Object],[object Object],Richard O. Brown](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (12)
Similaire à 10452 Human Resources Payroll Reporting Decentralizing Reporting And Automating Routine Analysi
Similaire à 10452 Human Resources Payroll Reporting Decentralizing Reporting And Automating Routine Analysi (20)
10452 Human Resources Payroll Reporting Decentralizing Reporting And Automating Routine Analysi
- 1. Human Resources/Payroll Reporting: Decentralizing Reporting and Automating Routine Analysis/Reconciliations Session #10452 March 23, 2005 HEUG 2005 Conference Las Vegas, Nevada
- 3. Preface: Our problems are man-made, therefore they may be solved by man. And man can be as big as he wants. No problem of human destiny is beyond human beings. John F. Kennedy
- 4. Preface: The problems we face are 98% people, 2% soft. Richard O. Brown
- 16. Background: University of Louisville
- 38. Automation by Using External University Data and Internal University Databases
- 54. Other Uses
- 56. Conclusion
- 58. Richard O. Brown Business Analyst Human Resources University of Louisville E-mail: [email_address] Contact
- 59. Discussion
- 60. This presentation and all HEUG 2005 presentations will be available for download from HEUG Online http://heug.org
Notes de l'éditeur
- From a technology standpoint, this topic may be rudimentary to some; some thing complex to others. From a business process standpoint, this topic represent current practices in your department. To other, this may be something new. From a reporting standpoint, you may have crossed this bridge and are creating reports that I’d enjoy seeing/copying. Others may not see a need for what we’ve created in HR. Regardless, thank you for finding this topic interesting enough to come in and see what this is all about. If you are currently incorporating some of these processes into your business practices, please feel free to give me a business card. I’d enjoy hearing what your office is currently doing.
- A little background. Advantage to working this area and coming into areas that need improvement: learn table structure because, like in actuals distribution or in PAYGL02, things must be perfect. You learn quickly how invalid data can cause massive amounts of pain.
- In no way to I want to put my wisdom (or exhibit my lack thereof) in a category of a United States President, but I’ve said this since I first came to HR and I stand by my statement today. The problems we face are 98% PEOPLE, 2% soft. That does not say that people are stupid, negligent, etc. What it means is that our unwillingness to look at the big picture – our unwillingness to compromise – our inability to extract the “can” from the “can not” is the majority of our problems. Thinking “out of the box” is not just some statement used by all of these motivational speakers.
- Once again, today’s presentation is an attempt to marry a number of disciplines, in English. I will review the progress we’ve made since 1999 in reporting, reconciliations, etc. Like all groups, we’ve made the transition from paper to electronic reporting. Unfortunately, the big challenge that I see that the university faces is that we have over 600 individual departments, reconciling accounts, payroll, etc. 600 different ways, requiring scores of custom tools, and making room for interpretation and errors. One thing the central administration has been successful at is the decentralization of reporting and information dissemination. No longer are departments dependant on someone running a report for them on an ad hoc basis, nor are central administration employees subservient to the immediate needs of departmental business managers. Although, there is a trickle of request for reports that conform to a departmental custom needs. Which, leads us back to the statement about no standardized reconciliation process. The goal, and something that HR has been striving, is to make the reports work for us. Create reports that show us the exceptions, show problems, show things that don’t match up or could be problematic. Show us things that put us at risk. Furthermore, don’t’ require me to ask the question constantly. Automatically let me know when these issues exsist.
- Find defined problems – don’t tell me everything. Inform me of conditions that are so bad that I’ve programmed you to basically tell me “Stop what you are doing and go look at this!” Summary Data: I don’t have time to go through 1,000 pages, and run 30 queries to tell me what’s going to blow up today. Give it to me “MTV.” Three or four minutes, make it flashy and… Accurate…don’t send me on wild goose chases. Make sure the report is accurate. Minimize Time Spent – Once again, I don’t have time to run 30 queries every day. I need it quickly Make it Easy – I’m not a programmer, and technology changes daily…it seems. Make it easy.
- To departments, that front end of PeopleSoft, that panel IS their data. They know nothing and don’t care about the back end systems or set up involved. In some cases, many artificial challenges and road blocks are erected based upon this false understanding that that data is saved verbatim in the format of that panel. For some here, that approach may be absurd, but I’ve seen this mistake and heard the “hammer and nails” of the barricade from change based upon this fallacy. PROD may be a transactional system, but in elementary terms, it’s a GUI front end for a database. Crystal and Crystal Enterprise allow edit or exception reporting to be decentralized. So, if a specific report needs to be run, and data “cleaned up”, HR specialists, analysts, etc. can run reports on their own and fix data specific for their areas of concentration without a supervisor’s or other central figure’s involvement. One tool that I know is needed, but I also see as problematic because of its use is MS Excel. Excel is NOT a database. You may be able to do simple mail merges and form letters, and it may be very easy to enter and store data, but it is not the optimal tool for reporting data. And, lets think about it. Why do you store data? Why do you input data? Answer: you plan to process the data and create some sort of output (list, analysis, SD, trend analysis, etc.). Excel is fine if you are analyzing the data in the spreadsheet, but if you need to join it reliably, with other data sources, Excel is a dead end.
- The reporting approach is pretty simple: unless your data is some where I can access, it’s worthless. Reportable data needs to be stored where a reporting tool, like Crystal or Crystal Enterprise can find it. ODBC (Open Database Connectivity) is a wonderful technology allowing databases to communicate with each other, and with other ODBC applications (such as Crystal®, MS Access®, MS Excel®, etc.). But, if your data is on paper, or some other document that is not readily accessible, it might as well not exist. Reporting that type of data literally requires building the wheel, every time. Contrary to belief, Excel is NOT a database.
- Tool are the same. And this is good.
- Functional Business Process: What tasks are performed to accomplish task X? Tech Skills: This relates to the technical skills of both your IT/technical personnel and your departmental personnel. Example, you may envision a web page that automatically checks what a user enters into an input field. If your programmer/web page creator does not have skills in Java, JDBC, etc., then the entire project may be in jeopardy. Also, if your departmental staff does not know how to take an extract into Excel, sort and calculate a standard deviation (if required), your business processes and finances could reflect that lack of skill.
- Technical tools: Basically, here are the technical tools that we use in HR to keep, manage, reconcile, etc. our data. Our production and EPM PeopleSoft instances maintain data on Oracle databases. The work very well, but since we do not have any DBAs of our own (and since Oracle can be very complex), we use MySQL to maintain data that we normally or for some other miscellaneous reasons can not keep the data in PeopleSoft. Examples would be our Microsoft Project, survey, and some employment application data. I mention MS SQL Server because I know many of you maintain your PS data using MS SQL Server. Bottom line: all of these data repositories are ODBC compliant systems. And, since Crystal and Crystal Enterprise work from ODBC data sources, it’s a perfect match for bringing together data from two different systems. Unlike the Crystal version that is native to PeopleSoft, Crystal 10 and Crystal Enterprise are not native to a PeopleSoft instance. Therefore, the thesis of this presentation is: use tools like Crystal and Crystal Enterprise to bridge multiple data systems to do the work automatically that would normally require either paper, visual line item, VLOOKUP or some other manual form of reconciliation. Which leads to the business/management analysis approach: bringing all of these facets together.
- The third approach used in this presentation is one of a a facilitator. Usually, business processes are examined or a specific departmental task may come under scrutiny because of an audit (either business process or financial), customer complaints, or the accidental discovery of data/information that someone finds either questionable or disturbing. As part of that process, one must define the problem, specifically. Look at the business process. Avoid artificial barricades, as well and find ways around others.
- Now, here is an odd thing. Query as a verification tool? Yes, I use Query to validate some of the tools I create in Crystal Reports. I also may create something using query, then replicate it into Crystal, using a reporting database. If I get the same results, then life is good. If something doesn’t work, then maybe either the Crystal report is flawed, my query is flawed, or the reporting table is flawed (which can really ruin your day if you are already using that table on a periodic basis for many of your current business processes).
- Crystal Reports. No, this presentation is NOT sponsored by Business Objects. I’m sure there are other tools that could be used. I’m just not familiar with them due to my “box” at UofL. I don’t get to try out other packages often due to my workload and job duties. And, here’s another odd thing. Output…yes. Crystal creates output. … to Excel? Wait a minute…you said Excel should be avoided. No, I said it should be avoided to store data. Most of the tools in Excel are financial tools. Excel is great for manipulating data, but not for long-term storage and reporting. What Excel IS good for is creating flat files (or ASCII text files) for feed either via App Engines, SQRs, or SQL worksheets into the system. Finally, since Crystal Enterprise is a web-based, system there is no client software, except for an Active X plug in that is installed the first time you run a report. All you tech support folks: imagine installing ODBC connections on every PC in your office. Imagine when IT changes ports or builds new servers how much time it takes to make those changes on the machines. With CE, make the one change on the server, and you are finished.
- Bottom line: everything that you can get your hands on is a potential tool. Everything from a multi-million dollar database server, to a Post It® note. Use what you have, and don’t be afraid to go shopping. Ask questions. Have brainstorming sessions. Meet with other areas and see what they are doing. Maybe a derivative of a process or technology use could be a life saver in your department.
- Find Data Issues: Find problems that could create extra work in the future. Example: if the department numbers on the position data table and the job data table are not synchronized, relative to the position and number and effective date, the actuals distribution process will post payroll expenses to a departmental default speedtype. This could charge the wrong program or grant, and could create deficits. Prevent show stoppers: When posting payroll related expenses to the general ledger, via the PAYGL02 SQR, the process will stop, cold, if the program detects an attempt to charge payroll expenses to an account code, whose program or grant is invalid or expired. The query tool can find these potential land mines, and give the operator a real time tool to proactively address these potentially time consuming and frustrating issues. Potential setbacks when using the query tool. Temp space: Sometimes, we simply ask too much of the query tool. Multiple unions, millions of rows of data, sorts, aggregates, outer joins, etc. can bring a query to its knees. Summary/Analysis: There is no way for the query tool to provide both detailed data and summary information. Also, unless you are an experienced SQL programmer and know how to “fool” the query tool, providing other types of figures (standard deviation, mode, etc.) are difficult to access. External Data Sources: Being that the PeopleSoft Query tool is a proprietary tool, it can not access external data sources (other databases). Query volume: considering that each query is written to find or detect a specific type of issue, and since there are dozens/scores of potential landmines for an HR operation, the volume of queries required to keep data “clean” is staggering. Running each query takes system time, as well as analytical and data repair/clean up time.
- Now, at this point, we are running reports based from only one database, or one database instance, or one database server. We may be extracting data from multiple instances or systems and storing/creating reporting tables in a reporting database. Such as the case of storing both Financials and HR data in the EPM database. Once again, from a report writing standpoint, EPM is nothing but a database that I can run reports against via ODBC. But, at this point, all databases are of inter-university origin.
- Up to this point, all reports have been created from internal UofL databases. Things are about to change.
- The first item is something that we currently have in production at UofL. The second is something that we have discussed with our health insurance vendor, and access to our data via ODBC has been added to the recent RFP for new health care management for the upcoming year. But, in lieu of a direct ODBC connection, we have developed a temporary workaround. Since as you could guess, health care is a big ticket item, but why stop there.
- In order for you start the process, you must ask yourself the question that plan to ask the computer. What question are you searching to answer, exactly? Remember that the computer is dumb. Regardless of who you are giving the instructions (directly to the computer, or the person writing the report), you have to ask the computer a question that it can understand, and answer. Otherwise, you will get exactly what you requested, from the logic standpoint of the computer.
- When considering how to compare data, one greatly overlooked item is how to create a relationship between the two data sets. It doesn’t matter if you are joining fields together, or comparing fields: there computer can only compare apples to apples. If your employee Id is saved in a proprietary database, and is an INTEGER, you will not be able to compare that to a PeopleSoft emplid, unless you do some conversion using some of the standard conversion statements. Also, if one database has a social security number as nine characher digits, no hyphens, and your second database has hyphens in the social, you again have more data conversion issues.
- The great thing again, about using Crystal Enterprise is that you can totally decentralize your reporting functions. Yes, you still need someone to write the reports, but once they are written,
- Health insurance is a major fiscal headache. The university is self insured, and contracts with a health care provider to manage our health plans. The plan is funded by periodic contributions from the employee and the employer.
- Now, if you think about it, there is an abundance of items that require account.
- Personal information: this can include employee address (where an employee changes address in one system but on another), SSN, etc. With regard to employee eligibility, we take it a step further and say: OK, we have them in the system as eligible for coverage X, but they could be in the health maintenance system as participating in coverage y (which they are not eligible). Furthermore, they could have terminated employment from the university, and still show as active in the health plan and not enrolled in COBRA. Or, do we have someone on our system, that is not is not in the health maintenance system? If not, then that employee will be calling our office wanting to know why they have not received their health insurance cards. Speaking of employment status, has a terminated employee filed a claim? If so, was that claim paid? And, even though I admit that we are not there yet, it would be nice to reconcile to the penny what the health maintenance database shows as total claims with our general ledger account of expenditures.
- Currently, since our health care maintenance agreement does not require an ODBC connection to our data (and yes, I call it our data), we can only access it via a web interface, and save as Excel. Here we go: I’ve said that Excel is not a database. And in order to compare this Excel spreadsheet to UofL data, we’ll have to take an extract of our data, export to Excel, create a VLookup and sort out the formatting errors from the “real” problems. This is not an optimal solution. And, if you are always facing budget cuts like we are, you know that resources are scarce, and becoming even more so. Furthermore, now you need someone that is pretty savvy with Excel in order to make this comparison. As you remember from the last page, there are a number of reconciliations that could expose any holes in your fiscal controls of your health care plan.
- If you have defined issue types, you can run reports/analysis on the type of issues are reported (benefits, paycheck underpayments, overpayments, claims, etc.). By comparing those type of issues to PeopleSoft by emplID, department ID, or who is responsible for X issues, you could identify communication or training problems that if addressed could save your department countless hours by addressing issues proactively either through better/more effective communication or training of “help desk” personnel. I’m sure your organization has other types of benefits that are supported strictly by employee participation or your organization acts as a fiscal agent for collecting the fees/premiums. This could help you locate problems with payments that for some reason did not go into arrears. Remember: if an employee didn’t get a paycheck, the system does adjust for arrears. The one issue that I’m looking forward to finding a solution is to compare addresses to a database of tax districts (and if any of you know of a good one please see me after this session) to determine the correct local tax district. In Louisville metro, we have four zip codes that span two counties. If you live on one side of the street, you could be in a different local tax district, and you can not always rely on the employee to furnish this information. By comparing these data sources, and running the report periodically on the scheduler before the opening of pay sheets, we could eliminate a great deal of incorrect local or state tax withholding.
- I’m happy to entertain any questions, suggestions, or discuss what your institution is doing to address some of these issues. By no means am I suggesting that this is the only or best way to accomplish the goals of expiditiously reconciling fiscal affairs, lists, etc. This is the direction that we in UofL HR are currently heading, and implementing as a prodution business process.
- I’m happy to entertain any questions, suggestions, or discuss what your institution is doing to address some of these issues. By no means am I suggesting that this is the only or best way to accomplish the goals of expiditiously reconciling fiscal affairs, lists, etc. This is the direction that we in UofL HR are currently heading, and implementing as a prodution business process.