It went to production!

It took a while. The prework, the process development, the waiting for development, the development process… but it finally went live, and my simple little process is now in our production environment.

The Problem

The problem was a simple communications problem. In our recruiting process, we need to assign accounting line numbers to our job requisitions. These are usually requested by the recruiter from our transaction processing team once the candidate has been selected but has not yet started. Unfortunately, the communication around this process was email based and frequently became confusing and challenging for both the recruiting team and our transaction processing team. Having witnessed the issue firsthand, I set out to find a solution. What if they could just push a button on our web interface?

 

Too much email, too little detail

For a line to be assigned, we need certain information. This information is collected in the job requisition, but is does not always get passed along with the transaction processing team.  This creates additional communications (lean concept: waste) between the transaction processing team and the recruiter. The required information is:

• Requisition Identification Number
• Job Title Identification Number
• Job Title
• Department Identification Number
• Department Name
• Full Time Equivalent (FTE)
• Pay Basis
• Account Number(s) where the expense is allocated to   

For the application, we needed additional information:

• Request Date
• Requestor
• Recruiter

With this information, we can automate the request process. Just a push of a button and the request can be made. With this information being in the system, the system can call this information and pass it to the request processing team for processing. The transactions processing team can then see the requests on their dashboard. Of course, sending the transaction processing team a notice that action is required and a confirmation to the recruiter that the process is in motion helps with the human factor until we can fully automate the line selection process.

 

What does this process look like?

In conjunction with representation from recruiting and the transaction processing team, we developed this flowchart to show what the process looks like. I am the rare bird that gives the development team flowcharts and identify the necessary database attributes, but they seem to appreciate it and it makes the coding process more efficient than trying to otherwise explain what we are trying to accomplish.

Request-A-Line Flowchart

There were changes in the development process after coding started that were not captured in the flowchart. My favorite improvement came up from recruiting where it will display the required codes and inform the requestor to cancel out of the confirmation notification to make any changes if any of the information is incorrect.

 

How is it working?

It is too soon to tell. I wrote up a brief how-to document for the recruiting team and the communication to the team is being managed by their leader.  The members of the recruiting team that engaged in the project’s development were quite excited and wondering what else we could apply similar logic and processes to.  The transaction processing team is small and even more instrumental in the development of the process. All-in-all, everyone is excited about the rollout and understands that things might not be perfect, and we will make updates to improve the process, as needed. In my opinion, the bigger win was helping people see that the don’t have to be satisfied with the system in its current state.  If they have an idea to improve the processes and pitch the improvement. Seeing people open their eyes to the possibility of change is more magical that we can ever do with these magical boxes of sand  silicon.