Business Analysis

Why freight technology projects go sideways

Ask why a TMS rollout, an EDI project or an accounting conversion went over budget, and the answer usually traces back to the beginning. Nobody wrote down what the business actually needed. The vendor demoed what the software does well. Leadership assumed the new system would "do what the old one did." Dispatch, billing and payroll each had different ideas about what mattered most. Then, three weeks before go-live, someone discovers that the new system doesn't handle split loads, or multi-stop detention, or the percentage pay plan half the owner-operators are on.

That's not a software problem. It's an analysis problem. And it's preventable.

Freight is full of details that look small on a whiteboard and turn out to be critical in production:

• Customer-specific tariffs, minimums, mileage bases and fuel surcharge schedules
• Accessorial rules for detention, layover, stop-offs, lumpers, hazmat and TONU
• Driver pay plans: loaded and empty miles, percentage of revenue, hourly, stop pay, and deductions
• Brokered loads, carrier pay, and settlements for owner-operators
• EDI obligations to key customers: 204 tenders, 990 responses, 214 status messages, 210 invoices
• Reporting that the owner, the bank, or the auditor expects every month

A business analyst who doesn't know these terms will miss them. A business analyst who has worked on the dispatch floor and in the database won't.

What our business analysis covers

Strong Tower provides business analysis as a standalone engagement or as the first phase of a larger project. The work is the same either way: understand the business, write it down, and make the gaps visible.

Stakeholder interviews

We talk with the people who run the business and the people who do the work: owners and executives, operations managers, customer service, dispatchers and planners, billing, payroll, safety, maintenance, accounting and IT. Each group sees a different slice of the same load. We bring the slices together.

Current-state documentation

How work flows today, by role and by system: which screens are used, which spreadsheets live on the side, which reports leadership depends on, and which interfaces move data between the TMS, ELD and telematics, imaging, fuel cards, EDI partners and accounting. We also document the pain points and workarounds people describe, because they're often the best requirements you'll get.

Future-state design

What the business needs to look like to support where you're headed: new lanes or service types, acquisitions, a shift toward brokerage, dedicated contracts, intermodal or drayage moves, or simply more loads with the same office staff. Future state is written in business terms first and system terms second.

Requirements

A prioritized, plain-language list of what any solution must do, should do and could do. Each requirement is tied to a real scenario from your operation, such as "a three-stop load with detention at stop two, billed to a customer on a weekly consolidated invoice," so it can be tested, not just checked off.

Gap analysis

A side-by-side view of your requirements against what your current system, configuration and processes deliver today. Some gaps close with setup changes or training. Some need custom work or an integration. A few might justify a new system. The gap analysis tells you which is which.

Business cases

When a decision involves real money, leadership needs more than a feature list. We lay out the cost of staying and the cost of changing, including licenses, services, internal time, training, conversion risk and the operational cost of the gaps themselves, using your own volumes and data wherever possible.

Carrier Technical Requirements Scoping & Gap Analysis Matrix

Transportation business analysis fails when requirements are written in generic IT terms like "system must track orders." Strong Tower writes deterministic operational specifications across five core freight architectural domains:

How a business analysis engagement runs

1. Frame the decision. We start with the question leadership needs answered: Should we replace the TMS? Can we take on this customer's EDI requirements? Why does billing take so long? What will this acquisition do to our systems? The question sets the scope.
2. Gather. Interviews, floor observation, document review and a look at the system and data themselves. We pull samples of real loads, invoices and settlements so the analysis is grounded in what actually happened, not what people remember.
3. Document. Current-state maps, future-state design and requirements, written so a dispatcher and a CFO can both read them.
4. Validate. Each department reviews what we wrote about them. Corrections happen on paper, where they're cheap, instead of during go-live, where they're expensive.
5. Analyze and recommend. Gap analysis, options and a business case, with a clear recommendation and the trade-offs behind it.
6. Hand off. The output feeds directly into the next step: a TMS selection, a process redesign, an integration project, or a managed implementation.

Where business analysis pays off

Analysis grounded in your data

Interviews tell you what people believe. Data tells you what happened. We often pair business analysis with a look at your TMS database to test assumptions: how many loads really need manual rating, how often settlements get corrected, which customers drive the most billing exceptions, how much freight runs on lanes that don't cover their costs. That keeps the analysis honest and gives the business case real numbers (see SQL Data Mining & Analytics).

What the analysis usually uncovers

Every company is different, but some findings show up again and again when we document a freight operation end to end:

• The system can already do it. A surprising share of "gaps" turn out to be features that were licensed but never set up, or set up once and abandoned. Closing them costs training and configuration time, not new software.
• Spreadsheets are running the business. Rate quotes, driver pay exceptions, customer scorecards, fuel reconciliations and lane analysis often live in workbooks outside the TMS. Each one is a requirement nobody wrote down, and a risk if the person who maintains it leaves.
• Departments define the same thing differently. Operations counts a load when it's dispatched, billing when it's invoiced, and accounting when it's posted. Revenue per mile looks different depending on who runs the report. Agreeing on definitions is often the most valuable thing the analysis produces.
• Customer requirements drive more than you think. A handful of large shippers often dictate EDI formats, invoice layouts, appointment rules and reporting. Their requirements belong at the top of the list.
• The real bottleneck is a hand-off. The slow step is rarely inside one department. It's the gap between two of them, where nobody owns the work.

Seeing these patterns written down, with examples from your own loads, is often what moves a leadership team from debate to decision.

What you get

Who this is for

Owners, CFOs, operations managers and IT managers at carriers, brokerages and 3PLs, intermodal and drayage operators, and private fleets who are:

• Facing a big technology decision and want it made on facts
• Preparing an RFP or vendor evaluation
• Mid-implementation and unsure the new system will cover everything
• Integrating an acquired company
• Tired of the same back-office problems coming back every quarter

Not sure where to start? Our engagement approach begins with an assessment, and business analysis is often the first piece of work that comes out of it.

Frequently asked questions