Construction finance manager reflects on working with ERP consultants after becoming one
Q&A with Jerilyn Underhill, SIS Senior Industry Consultant
Interview by: Sarah D. Morgan, Senior Staff Writer – Construction ERP
In this month’s THESIS Q&A, we talked with Jerilyn Underhill, former Construction Financial Planning & Analysis Manager and new SIS Senior Industry Consultant. Jerilyn shares lessons learned from her experience working with outside ERP software consultants to her new role as an ERP Consultant. In her finance role, Jerilyn often felt software consultants were not providing complete information and not collaborating with her as transparently as she wanted during system implementations.
After many years in the finance area of a global construction company, Jerilyn has become a construction industry ERP Consultant. She is now in the exact role she interacted with, and her eyes are open to the reasons, methods, and guardrails software consultants use to protect both the company performing the implementation and the consultants partnering with them. Projects she reflects on in this THESIS Q&A include Lean Thinking for the construction back office and multi-system consolidation using a major construction ERP.
Q: Tell us about your career before you became an ERP consultant.
A: For 20 years, I managed an accounting department, including payroll, project costing, and financial planning and analysis groups. I worked with each company level regarding systems —project, regional, corporate, executive, and external parties. At one point, I was asked to build a team using lean thinking to redefine companywide back-office business processes by maximizing technology.
Q: Before we get into the heart of the comparison from being a client to becoming a consultant, what can you tell us about lean thinking for the construction industry and the project itself?
A: We wanted to apply lean thinking, focusing on value while reducing waste in our back-office processes. We collaborated with our stakeholders to identify many painful processes across our companies and zeroed in on those yielding the most significant benefit. We had support for the initiatives that spanned from our Board of Directors to our field teams and everything in between.
A couple of the more significant improvement projects we tackled were eliminating paper timecards and moving a recent acquisition to the same instance of the solution. We were maintaining two instances of the solution, which was inefficient because we had the additional cost of the servers, maintenance, updates, support, etc. This is where we started adopting lean thinking by consolidating steps and saving time and money. We reconfigured our processes to ensure the people were ready for the work and the work was prepared for them to eliminate the wait time between steps.
We changed how we worked. We condensed into one instance of the solution and went through procedures throughout the company to ensure our stakeholders, the people doing the work compared to the people far removed, were part of the decisions building the process. This changed the whole company mindset and got others involved to start becoming a process team instead of, for example, just a payables team or a person who processed payables.
In that manner, we used change management to apply lean thinking, which was successful because the change messaging came from the executive teams. If we wanted to become more efficient as an employee-owned company, anything we saved would benefit everyone. This lean processing was not about cutting people. It was about cutting out red tape while maintaining controls and having people do the right work at the right time.
Q: Tell us about the diverse types of ERP consultants and how you interacted with them as a Financial Planning & Analysis Manager.
A: I worked with lean process and software consultants on system initiatives. I collaborated with both independent consultants and company consultants. We implemented a major construction solution as our platform of choice early in my career. Our engagements included the initial implementation, major upgrades, creating new instances for business isolation, and launching new modules. Additionally, our equipment company implemented a different construction solution.
While working with the software consultants, I must say, I kept their feet to the fire. I was always trying to look in and gain more access behind the curtain of the system, challenging their logic at times with the thinking that we were the customer, and it should be our way. I pushed them to get more into the business process, not just the software process. I possibly felt a bit of entitlement to their time because we were paying them. They should be able to snap their fingers and make things happen. Now, as a consultant, I see behind the curtain and recognize that I was blind to how the process worked and how they protected me and the company.
Q: As an industry ERP consultant for construction solutions now, what does your previous experience teach you about both sides of the fence?
A: I see now the consultants weren’t trying to stonewall me. They had solid reasons for not allowing me in the back end of the system and why they wouldn’t go deeply into processes.
It seemed we were getting guidance on how to push the buttons. Still, we wanted to see behind the curtain how it all came together—the mechanics, the connection points, and the decisions being made in the configurations so that we had a connected vision of the process.
Bridging the gap between system functionality and real-life processes is one of the most challenging discussions for both sides, as both sides must see and understand each other’s perspectives.
Q: So, what have you learned on the other side of the fence about setups and user requests?
A: Now I understand that you can’t give users everything they want because changes involve a scope of work and costs. I see the criticality in locking in the scope, so the bar doesn’t keep moving. When the scope moves, it impacts the timeline. There are true professionals on the system side working toward the most efficient and effective configuration for the client in testing, processing, and promotion, and we should trust them while they address our requirements. They have enabled guardrails to keep the clients from hurting themselves.
As a user, you engage with just one person when, in fact, that single contact has a whole host of support at their fingertips. Functional, technical, business, PMs, industry, and security folks are resources in and of themselves. They seek out what’s best for their client and the continuing efforts of the developers themselves.
I would have given more grace if I knew then what I know now. Users behind the scenes are working hard and indeed working to do what they can to assist, but their hands are tied for valid reasons. I’m glad to have that perspective with me today.