ERP Business Analyst in Dallas

Homebuilders and land developers: lots, options and warranty

North Texas has been adding new homes at a fast pace, and the growth has pushed builders and developers north into Collin and Denton counties and outward in every direction. Their processes are distinctive. Land is bought or optioned, developed into sections, and lots are taken down on a schedule agreed with a developer. Each house combines a plan, an elevation, a lot and a set of buyer selections made at a design center. Purchase orders are released by construction stage, variance purchase orders appear when something goes wrong, and the closing happens through a title company. After closing, warranty requests arrive for months or years.

Requirements for a builder have to say where each of these records lives. Some builders use specialized homebuilding software for construction and keep a general ERP for finance; others want one platform. I document lot status, option pricing and change cutoffs, how job costs roll up by community and phase, how deposits are held, and how warranty requests are logged, assigned to trades and closed.

The questions that matter most are often about exceptions: a buyer who changes an option after the cutoff, a lot swapped between buyers, or a trade partner who bills before the inspection passes. Those scenarios become test cases. For broader property and development requirements, see the real estate ERP page.

Franchisors: royalty, marketing fund and franchisee reporting

Dallas and its northern suburbs are home to a large number of franchisor headquarters, especially in restaurants, fitness, home services and personal care. Franchisors run an unusual revenue model. Instead of selling goods, they bill franchisees a royalty and a marketing fund contribution based on reported sales, plus technology fees, training fees and new-unit fees. Some systems also have area developers who share in fees from their territory.

The requirements here are precise. Where do franchisee sales come from: a point-of-sale feed, a portal where franchisees report, or a spreadsheet? What happens when a report is late or later corrected? How are royalty rates stored when different franchise agreements carry different terms? How is the marketing fund kept separate in the books, and how is spending from it tracked? How are drafts from franchisee bank accounts scheduled, and how are failed drafts followed up?

I write each rule as a requirement with an example calculation in words, and I separate what the ERP should do from what belongs in a franchise management system or the point-of-sale platform. Questions about what the franchise agreement or disclosure document allows go to your franchise attorney, not into my assumptions. The national requirements topics, such as vendor reporting and approval controls, are covered on the US ERP business analyst page.

Texas tax touchpoints, written as data requirements

Texas brings its own tax details, and I treat them as data questions rather than tax advice. Texas sales and use tax combines a state rate with local rates from cities, counties, transit authorities and special districts, and Texas has its own rules on which location's local tax applies. Some services that are not taxable in other states can be taxable in Texas, so a services business should not assume its invoices are exempt.

The Texas franchise tax, often called the margin tax, is calculated from revenue and certain deductions, and the method chosen affects which cost data the accounting team needs to report cleanly. Texas also taxes business personal property, and certain inventory exemptions can depend on whether goods are shipped out of the state within a set period. That makes ship-to state and dates on inventory movements worth capturing reliably.

In the requirements set I list the fields, codes and reports that each of these touchpoints depends on: customer and item tax codes, location data on every sale, cost categories mapped for the franchise tax method your CPA prefers, and inventory movement history by destination. Your tax advisor confirms the rules, and I make sure the system can store and report what they need. The requirements gathering page describes how these items sit within the wider set.

Bilingual crews, warehouses and service teams

Across Dallas-Fort Worth, a large share of the people who build houses, install systems, pick orders and clean buildings speak Spanish as their first language, and some teams work in Vietnamese, Korean or other languages. An ERP project that designs every screen and label in English for the office staff can leave the people who generate most of the transactions struggling to use it.

I capture this in the requirements explicitly. For each role I note which screens they use, which documents they read, and whether they work on a phone, a scanner or a desktop. Then I record what must be available in another language: mobile forms for field crews, pick tickets and bin labels, safety and inspection checklists, and short training guides. I also note what can stay in English, because translating everything is rarely needed.

The engagement itself runs in English. Any translated wording comes from bilingual colleagues in your company or a translation firm you appoint, and I make sure the requirement specifies who approves it. Vendors are then asked to show how their system handles language per user, translated print layouts and mixed-language data such as item descriptions, which avoids unpleasant surprises during training.

From interview notes to a signed-off requirements set

The deliverable is a requirements document your team can own, not a binder that disappears after selection. It opens with a short description of the business and its scope, followed by current and future process maps for each area, numbered requirements with a priority and an owner, a list of reports and dashboards with their purpose, integration needs, data conversion notes and an open-questions log for items that need your advisor or attorney.

I review each section with the people who described the process, in short remote sessions, and they confirm it in writing. That sign-off matters when a vendor later claims a requirement was never raised. The same numbered list then drives demonstration scripts, the fit-gap matrix and, after selection, user acceptance test cases, as explained on the ERP testing and UAT page.

If you would like an independent advisor to stay involved through selection and implementation rather than only the requirements stage, the freelance ERP consultant page for Dallas explains how that works. The Dallas ERP consultant page covers multi-unit operating model questions that often come before detailed requirements.