John belanger solution oriented case studies

JOHN MICHAEL BELANGER
Business Analyst

Solution Oriented Case Studies

The information in this document is confidential and may not
be distributed without prior consent

Business Analyst

Solution Oriented Case Studies

This document will provide a number of case studies demonstrating my ability to engineer processes
and systems to drive waste out of business, creating a more efficient and cost effective business model.

Table of Contents

A Driver Training Data Solution 3

An Asset Management Solution 4

A Lease Document Creation Solution 5

A Deal Structure and Approval Solution 6

An Early Warning Risk Remediation Solution 7

An Invoice Processing Solution 8

A Solution For Enabling IC Capacity 9

John M. Belanger Solution Oriented Case Studies CONFIDENTIAL - DO NOT DISTRIBUTE Page 2

A Driver Training Data Solution
Train Trax

Background
For many years, Schneider National, Inc. hired and trained inexperienced truck drivers to fulfill their demand for
driver capacity. Several Schneider Training Academies were opened in the United States and Canada to meet this
demand.

Problem Being Addressed
Schneider Training Academy (STA) did not have a good methodology for tracking student progress, student
success or trainer performance. A trainer was considered to be doing a good job if they showed up for work and
had no complaints from students.
Training decisions were being made in a vacuum with limited historical or trending data to support business
decisions. Data was kept on an individual student basis in a main frame system, but there was no way to aggregate
the data to identify gaps in curriculum, trainer effectiveness or student failure rates.

The Approach Taken
Hired to manage the over-the-road portion of training, I immediately identified that training decisions were being
made in a vacuum, with no historical data being used to evaluate student or trainer performance.
Using basic Microsoft Office tools (primarily MS Access), I created a tracking system dubbed Train Trax. This
system was designed to:
 Track student performance
o Classroom Test scores
o Driving evaluation scores
 Track student success
o Successful CDL
o 30-60-90 day tenure performance
 Evaluate trainer performance
o Identified most effective and least effective trainers
o Continuation in the training program based in part on the data collected through Train Trax

Train Trax provided trending data as well as a real time dashboard for the current class of students. In addition,
Train Trax performed some basic administrative functions such as creating student name tags and printing
diplomas.

Problems Encountered
 Initially there was some resistance from some of the trainers. For the first time ever, their performance and
effectiveness as trainers was being tracked and reported.
o This issue was addressed by training as well as group and individual business partnerships.
 Bandwidth constraints precluded the ability to put Train Trax on the network to be accessed by all of the
Training Academies throughout the United States and Canada. Yet it was important that the data be
aggregated.
o This issue was solved by a daily data exchange. Each stand alone copy of Train Trax created
export files on a daily basis and sent these files to the corporate headquarters, where the data was
imported into a "master" database.

Outcome
 Student scores improved as the data identified subjects that either needed additional training, a different
time slot or enhanced training materials.
 Overall training time decreased producing revenue generating drivers sooner.
 Trainer performance improved as ineffective trainers were given additional training and resources to be
more effective.
 A "One Trainer" model spawned from the data that suggested there is a drop-off in knowledge when a
student transitions from one trainer (their in-house trainer) to a second trainer (their over-the-road trainer).
A "hybrid" training position was created where a trainer kept a student for the duration of their training.


An Asset Management Solution
Asset Management System (AMS)

Background
Schneider Finance, Inc (SFI) is a commercial vehicle leasing company with a typical portfolio of nearly 1000
active leases at any given time. SFI purchases approximately 200 new tractors each year. In addition,
approximately 400 tractors are returned , most of which must be reconditioned and remarketed. Average
reconditioning costs typically exceeded $10,000 per asset.
Asset information was stored in a third party lease accounting system called Paragon, however Paragon could only
house basic information such as VIN, year, make, model and purchase amount.

 SFI had no processes or systems for managing asset reconditioning. Units being returned for
reconditioning were sent to the OEM for full reconditioning regardless of cost.
 All data was kept in paper files. There was no way to aggregate or report reconditioning cost data.
 There were no vendor metrics in place, so every vendor was assumed to be doing a good job and having the
best interest of SFI at heart.

The Approach Taken
Originally hired by SFI as the Asset Manager, I was accountable for getting processes and systems in place to
manage asset reconditioning, drive cost out of the reconditioning process and provide meaningful data to aid in
tractor purchasing and reconditioning decisions.
I created a series of databases that combined would be the Asset Management System (AMS). The primary
component of AMS was the Off Lease Assets database (OLA). OLA created a record for every reconditioning
event, tracking critical data such as: vendor data, estimated amounts, actual amounts, reconditioning time, ready
dates, lease dates, prior customer data and next customer data.
I implemented a reconditioning estimate process with vendors, creating a simple electronic estimate file that the
vendors would submit before any work was approved. The estimate was imported into OLA and a purchase order
was generated. Actual invoices were then automatically compared to the estimated amount and became part of a
vendor score card.
I established a relationship with a non OEM vendor who specialized in fleet maintenance. I negotiated a favorable
labor rate with this vendor and shifted much non-warranty work to this more cost effective vendor.
I conducted quarterly vendor reviews using trending data supplied by OLA. I was able to compare vendor to
vendor to determine which ones were the most cost effective and the most responsive.

 There was significant change management that had to take place.
o Vendors were accustomed to having a "blank check" to recondition units. I had to build
relationships with each vendor and communicate the overall reconditioning vision.
o Sales associates were accustomed to having equipment restored to as close to "like new" as
possible. In the new environment, an older high mileage truck had to be sold with some
cosmetic issues.

Outcome
 Reconditioning cost was reduced by 10% year over year. This was accomplished by selective
reconditioning (choosing to not repair some items that were not safety or DOT related), creative
reconditioning options (replacing a broken cabinet door with one taken off of a wholesale unit vs. buying
new), deferred cost (issuing a tire voucher for future purchase as opposed to replacing tires that still had
life on them) and instilling a cost control philosophy internally and with vendors.
 For the first time ever, vendors were measured and benchmarked against each other. Vendor reviews were
conducted on a quarterly basis and the highest performing vendors were rewarded with more work.
Vendors strived to be the most efficient vendor available.
 For the first time ever, reconditioning cost trends could be reported, analyzed and acted upon. Strategic
decisions could be made using factual data as opposed to being made in a vacuum.


A Lease Document Creation Solution
OASIS

Background
Schneider Finance, Inc (SFI) is a commercial vehicle leasing company writing over 600 leases per year. Every
lease requires complete and accurate lease documents to be created and executed. The lease documents, once
executed, bind SFI by the terms of the contract, even if they were created in error.
SFI was utilizing a Microsoft Excel spreadsheet to create lease documents. An associate would complete a row of
data where each cell would be merged to a corresponding field within the Lease Documents.

Utilizing an Excel spreadsheet created some inherent issues with data accuracy and security. As a result, Lease
Documents were often created in error, resulting in rework, or if not caught could expose the organization to
negative financial risk. Because completed rows could not be locked down, there were occasions where data was
inadvertently changed or deleted by associates.
The Excel file was also inefficient as only one associate could be using it at a time. This especially created issues
if an associate forgot to close the file and went to a meeting or lunch.

The Approach Taken
One option was to continue to utilize the Excel spreadsheet, but add cell validation, pull down menus and other
features to make it more user friendly. However, it would still lack the enhanced functionality and security that
Microsoft Access could provide. Therefore, I created a Lease Document system dubbed OASIS. Data was pulled
from other systems (Deal Maker and the Asset Management system) to ensure consistency and accuracy of data.
This reduced the likelihood of error that occurs when data is manually entered/re-entered.
OASIS would perform basic lease calculations such as interim interest, final payment amount, first payment due
date, heavy vehicle use tax and payment amortization tables. OASIS would also validate that the asset associated
with the prospective lease was in fact approved for the particular lease type.
OASIS is a multi-user database allowing multiple users to create lease documents at the same time.

 Since OASIS pulled data from other systems, if the data entered into those systems was inaccurate, the
lease documents would continue to be inaccurate. We recognized that this possibility exists, but still
believed that the fewer times the same piece of data had to be entered, the less opportunity for error.
o We reallocated some of the time that administrative associates previously used to create
documents and used it for document review.

Outcome
 Document accuracy improved and financial exposure was reduced. In addition, I was able to create metrics
to measure the performance of the sales group as well as the administrative associates responsible for
actually creating the documents.
 The time it took to create a set of documents was reduced from approximately 45 minutes per set to
approximately 15 minutes per set, including the time to review the documents for accuracy.
 The time saved was reallocated to lead generation and pre-qualification work which made the sales
associates more productive.
 Because documents could be created in a more efficient manner, Client Relationship Managers (CRM)
gained one full additional day to finalize deals.


A Deal Structure and Approval Solution
Deal Maker

Background
Schneider Finance, Inc (SFI) is a commercial vehicle leasing company writing over 600 leases per year.
Approximately 50 - 70 new lease applications are received on a weekly basis. Each application had to be
approved or declined based on current underwriting standards by two Lease Portfolio Managers who also served as
Credit Managers.

The volume of applications that needed to be reviewed on a weekly basis created a situation where a credit
decision often took three or more days. In many cases, the initial decision was actually a request for further
information, which delayed the decision even longer. In the event that one Credit Manager was out of the office,
the credit decision would fall to the remaining manager, and the decision would be delayed even longer. The time
that it took to obtain a credit decision resulted in lost opportunity as clients would often either withdraw or find
financing elsewhere.
In addition, since credit decisions can be subjective, having multiple credit managers increased the risk of
inconsistent credit standards being applied to credit files. CRMs would instinctively take their files to the manager
that they felt was more lenient.

The Approach Taken
I had an idea to create a credit decision making tool that would give the CRMs the ability to get a credit decision in
real time. Basically I had to build something that would apply human logic to raw data. I spent many hours
reviewing the underwriting standards and the credit decision making process. I interviewed the Credit Managers
to determine how they approached credit decisions and how much weight they put on each element of a credit file.
I then created a system called Deal Maker where the CRM could enter data from the credit application, the credit
bureau and additional information obtained directly from the client. After obtaining a credit application and credit
bureau, a fifteen to twenty minute conversation with the client could provide the CRM with all of the information
they needed to populate Deal Maker and obtain a credit decision. Of course exceptions could be brought to a
manager for approval.
Deal Maker weighted information in four quadrants: Work history, Credit history, Personal Obligations and
Stability. After completing the information in each quadrant, Deal Maker returned a approval or denial and if
approved would determine what type of equipment the client was approved for (new or used) and what type of
program the client was approved for (limited oversight or parental oversight).

 Putting the credit approval at the fingertips of the front line CRMs created an opportunity for intentional or
unintentional falsification. This would of course be a concern to our Internal Auditors.
o I addressed this issue by creating an auditing process that was individualized by CRM. Initially,
100% of a CRMs files would be audited by the CRMs manager. When the CRM was at full
performance, they would be put on random auditing and the auditing function would be handled
by an administrative associate.

Outcome
 Time from application to decision was reduced from between 3 to 5 days to no more than 24 hours, and in
most cases could be delivered same day.
 Over time, one Credit Manager and one Customer Service manager left the organization to pursue other
opportunities. In both cases, SFI did not need to replace those managers.
 As the CRM group grew from 5 to 8 associates (through internal job restructuring), there was no need to
increase management head count.
 CRM satisfaction and productivity increased.
 The number of tractors seated improved year over year and reached levels of over 600 leases per year.
 The auditing process satisfied the Internal Auditors.


An Early Warning Risk Remediation Solution
EWS

Background
active leases at any given time. Eight Client Relationship Managers (CRM) service an individual portfolio of over
100 active leases each. Each CRM is responsible to create new business and actively manage client success
through collaboration with the parent company, Schneider National, Inc. (SNI).

When dealing with client issues, CRMs had to pull data from a variety of systems to include a third party lease
accounting system, internal databases and carrier databases. This made assisting clients cumbersome and in most
cases precluded CRMs from being able to resolve situations in a single phone call. In addition, it was difficult for
CRMs to prioritize intervention activity to positively affect their portfolio.

The Approach Taken
Recognizing the inherent difficulty in managing a portfolio when key factor data is contained in multiple sources
and systems, I took the initiative to create an Early Warning Risk Remediation System (EWS). The vision was
basically a single source system that would put all relevant data at the fingertips of a CRM, so that they could
service a client in a single phone call as well as enable the CRM to prioritize their portfolio so as to focus on those
clients in the most need for intervention.
I worked closely with the parent company and third party vendors to gain access to their respective data tables.
Being the architect of Schneider Finances internal systems, I already had access to that data. I created a system
that would import data from all of the various sources on a daily basis, aggregate it by client and deliver it to the
CRM in a color coded dashboard format.

 Schneider National field operations leadership requested the EWS to be made available to the individual
Driver Business Leaders (DBL). Bandwidth constraints precluded the ability to put EWS on the
network, making it inaccessible to Operations.
o I was able to engineer a process to export the aggregated data to all operations field locations. So
now, the leasing company representative and the carrier representative were both operating using
the same data with the common goal of enabling IC success.

Outcome
 Client support improved dramatically because in most cases CRMs were able to resolve situations in a
single phone call. CRMs were able to talk factually as opposed to operating in a vacuum.
o For example, if a client stated that they were unable to make their lease payment because the
carrier wasn't providing enough miles, the CRM could reference the carrier miles fields in EWS
and know exactly how many miles the client was running.
 CRMs productivity improved because they no longer needed to research client data as it was all at their
fingertips. This time savings would be used to proactively intervene on clients who may be on the
bubble.
o For example, a client may be current with their lease payments, but if their take home pay was
suffering, it wouldn't be long before they would fall behind on their personal obligations, and
their business would fail. In this scenario, looking at lease payment delinquency would not tell
the whole story.
 By providing the EWS to Schneider National operations associates, SFI associates and SNI associates were
able to collaborate so as to positively impact IC success. This collaboration also eliminated the tendency
for clients to "play" one department against the other. The result is that turnover amongst Owner
Operators who leased a unit from SFI was typically 10-12% better than those who were not affiliated with
SFI.


An Invoice Processing Solution
Managed Maintenance Interface

Background
active leases at any given time. Approximately 95% of active leases participate in a managed maintenance
program. In addition, SFI reconditions approximately 400 tractors per year. Each reconditioning event involves
two to five vendors.
As a result, SFI handles thousands of repair invoices each month. Each invoice requires approval via a purchase
order, and in the case of a leased unit, repair cost has to be allocated to the clients individual managed maintenance
account. In the event that an authorized repair occurs within the first thirty days of the lease, the client is
responsible for a $100.00 deductible and then 50% of the balance. The remaining amount is paid by SFI.
Two full time associates manage the purchase order , book keeping and accounting functions associated with these
invoices.

Over time, as the portfolio size grew and more clients were participating in the managed maintenance program,
invoice volume nearly doubled. Spikes in equipment returns also contributed to increased volumes of invoices.
Handling each invoice on an individual basis was extremely time consuming, increased the opportunity for error
and resulted in associate burn out.
SFI was faced with the prospect of having to add significant headcount to keep up with the volume of maintenance
invoices.

The Approach Taken
I created a Managed Maintenance Interface to process large volumes of invoices without adding any significant
time using a Batch Invoice process. Working with our primary vendors, I was able to obtain invoice information
electronically in a table/spreadsheet format. For those vendors who didn't already have a downloadable invoice
table, I create an easy to use Master Vendor Invoice, and showed them how to use it.
Upon receipt of a master vendor invoice, the interface would import the data and determine if it was an authorized
repair by matching the purchase order to our PO system. If it was an authorized repair, the interface would then
determine if the repair was covered under the 30 day maintenance protection plan or as a pre-approved policy
exception. Based on that information, the interface would allocate cost to either the client's managed maintenance
account, SFI's general ledger or both.
After processing the master vendor invoice, the interface created an export file that could be automatically
uploaded into our third party lease accounting system.

 Those vendors who didn't already have an electronic table of invoices were sceptical at first. However,
when they saw how easy it was to populate invoice information, and much quicker SFI was able to
process their invoice for payment, they absolutely loved it.

Outcome
 SFI was able to process large quantities of invoices quickly and easily. We were able to absorb significant
volume increases without adding any headcount.
 Since the system produced an exception report, associates spend their time managing by exception.
 SFI was able to use the interface to create life cycle asset repair cost, which was never possible before.
This information will drive equipment purchasing decisions.
 Vendors were able to get their invoices processed quickly and accurately and get paid sooner. This was
especially important at month end where a spike in invoice volume previously could have delayed
payment a full week.


A Solution For Enabling IC Capacity
Enterprise Contractor Solution (ECS)

Background
Schneider National, Inc (SNI) utilizes Independent Contractor (IC) capacity to service their customer base, and
have an appetite to grow that segment of capacity. There are two separate companies that supply this IC capacity
to the enterprise. The SNI IC Recruiting department, tasked with recruiting and processing IC applicants and
Schneider Finance, Inc. (SFI) tasked with leasing equipment to ICs.
The SNI IC recruiting department utilizes a system called Taleo for tracking IC applicant progress while SFI
utilizes a system called Lease Complete to track its Lease application progress. Taleo and Lease Complete are two
different systems, on two different platforms, servicing two different companies with no way to link the data.

Because Taleo and Lease Complete are two separate systems, the two respective companies were often operating
in a vacuum. IC recruiting would be pursuing an applicant that had already been turned down for equipment by
SFI, and conversely, SFI would be pursuing a lease prospect only to find out that they've been turned down by
SNI.
This breakdown in communication created a lot of frustration, rework and cost in terms of lost productivity.
Instead of focusing our joint efforts on those applicants who were viable to both companies, each company spent
critical time pursuing leads that would ultimately be turned down.

The Approach Taken
An IT solution to solve this problem would have been extremely costly and time consuming. One or both
companies would more than likely have to abandon their system. Therefore, I created a cost effective, efficient
solution that satisfied all parties.
I worked with IC recruiting to get an automated file export from Taleo showing all IC applicants who had
indicated they were getting a tractor from SFI. This file contained applicant information, recruiter information and
status of the application. Being the SFI systems manager and project lead on Lease Complete, I already had access
to all Lease Complete data. I created a new field in Lease Complete to house the Taleo ID. This would be the
primary key that would link the two systems together.
I then created an interface in MS Access dubbed the Enterprise Contractor Solution (ECS) that would
automatically pull prospect information from Lease Complete and applicant information from Taleo. ECS would
then deliver a product that would provide visibility of both processes to both companies in real time.
So an IC recruiter could look up their applicant in ECS and see exactly who the SFI associate was and the status of
their lease application. Likewise, an SFI associate could look up their prospect and see who the SNI recruiter was
and the applicant status.
System reporting provided status updates without having to research applicant by applicant.

 Both departments had to be consistent with their processes. If SFI didn't populate the Taleo ID field in
Lease Complete, the connection would be lost. If IC Recruiting didn't flag an applicant as a "tractor
purchaser" in Taleo, the connection would be lost.
o ECS addressed this by searching both systems and identifying ICs that may not be coded
correctly.

Outcome
 Working together, SFI and SNI Recruiting were able to hit record number of new ICs per week. Class
sizes of new ICs went from an average of 10 or 12 per week to an average of 15 to 20 per week.
 The collaboration between the two companies improved. SFI associates and IC Recruiting associates
worked together on their common applicants to deliver revenue producing ICs to the enterprise as quickly
as possible.
 Both companies were able to prioritize their work. ECS provided SFI with a list of applicants already
approved by SNI, and SNI Recruiting was able to pull a list of prospects already approved for a truck by
SFI. This ability to prioritize work led to the improved results mentioned above.

Business Analyst
320 N. Oakland Avenue • Green Bay, Wisconsin
920.327.0158
Jbelanger629@gmail.com | www.linkedin.com/in/belangerjohn


John belanger solution oriented case studies

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Viewers also liked

Viewers also liked (7)

Similar to John belanger solution oriented case studies

Similar to John belanger solution oriented case studies (20)

Recently uploaded

Recently uploaded (20)

John belanger solution oriented case studies