People ask me what I do for a living. It's a fair question, one I certainly feel comfortable asking other people, and, yet, one I can't easily answer for my own career. I tell them I'm an "industrial mathematician."
A business operates some set of processes or activities within a set of limitations or constraints and realizes some kind of outcome, revenue or profit, from it. (How is that for a general definition of a business?) In its operation, a business makes choices or decisions that affect the outcome. The process of selecting the best decisions that stay within the business limitations is called "constrained optimization."
My education is in a field called "Operations Research," so named because it started as the study of ways to help the U.S. military after World War II. It is also called "Management Science" with similar fields called "Industrial Engineering" and "Engineering-Economic Systems." In one form or another, these fields specialize in constrained optimization, finding the best solution amid a vast array of choices, maximizing a given objective within specified limitations.
Those who specialize in these fields
are typically academic professor types
who teach courses and publish papers.
I have taught a course and published a
book,
but neither of these are what I do for a living.
Business organizations that do what I do
are sometimes called "Decision Support."
For
twenty-one years
I have worked in an office (nine years)
or a cubicle (thirteen years)
with a desk and a computer.
My job has been to find ways
to make things work better for somebody else,
better in some quantitative way.
My work usually helps
somebody make more, spend less, or save time.
An airline can decide which routes
should be flown with which airplanes
so most of the seats are going
where most of the passengers want to fly.
They want the biggest airplanes serving the biggest demand.
When this is done years in advance
to decide which airplanes to buy,
it is fleet planning.
When it is done months in advance
so the central reservations system (CRS)
can manage seat inventory,
it is schedule planning.
When it is done weeks in advance
to respond to shifts in demand,
it is demand driven dispatch.
And when it is done in the last few hours
to respond to unexpected events,
it is systems operation control.
All of these stages can benefit
from mathematically sophisticated
optimization models.
Several business,
including airlines, hotel chains, and railroads,
have a limited supply of seats, rooms, or cargo space
with demands at different prices.
The mathematics of yield management
determines which inventory is sold
to which potential customers
to maximize revenue.
A company selling and leasing used automobiles
bases its lease buyout price
on what a car is going to be worth in four years.
The more accurate their forecasts are,
the more money they can make.
Mathematical models can estimate
the revenue impact of price changes,
in a competitive environment or a local monopoly.
Some models calculate the revenue impact of customer loyalty.
Other models forecast market demand to maximize sales.
A cellular telephone system is a complex network
of radio towers (base stations),
telephone switches,
and communication links (trunks).
Mathematically planned deployment
of radio and telephone equipment
can serve a given demand with fewer
base stations and switches.
Lower equipment cost can be used for increased profit
or to lower prices for competitive advantage.
The railroad industry in the United States
has shifted from passenger service to freight transport.
We think of Amtrak and feel sorry for the dying railroads
while the rail freight business continues to grow.
In the United States
building a mile of new rail costs several million dollars
and maintaining it costs tens of thousands of dollars per year.
Figuring out
where to add new rail to satisfy increasing demand
or to reduce shipping delays
is a hard problem.
Mathematical models can estimate
the costs of various components of business activity.
Those models can help business determine
what they really need to spend
to serve their customers.
A printed circuit board designer
spends a great deal of time
designing a circuit,
placing component parts,
and laying out the routes or traces
that make the electrical connections.
Sophisticated printed circuit board autorouting software
shifts the designer's role from carrying out these tasks
to managing the board design process.
Software helps the designer work with the bigger picture,
making sure the resulting board serves customer needs.
Every mortgage in the United States
requires a certification that
the property is insured for flood damage
or is not in a designated flood plain.
These flood plain certifications involve hours of manual labor
rummaging through government-issued maps.
Image processing algorithms can convert
a computer-scanned picture of a map
into a database of flood plain regions
by latitude and longitude.
Time formerly spent sorting and searching through paper maps
can now be spent evaluating the cases where
a property is close enough to the edge of a flood plain
that human judgment is required to make the determination.
Airline planners dilute their expertise
spending hours and hours
comparing schedules and cataloguing changes,
matching departures and arrivals in a weekend schedule,
counting connections in a competitive market,
and tallying unplanned jet engine maintenance events.
Computer programs can perform these tasks
so people can use their time
figuring out how to run the airline.
Mathematical models
can perform repetitive tasks
and can make basic decisions
so experts can use their time being experts.
A central theme in all my work is that it helps
a community of people who do real work.
In my professional life,
I have never installed any telecommunications equipment,
booked airline tickets or hotel rooms,
flown or maintained an airplane,
dispatched a freight train,
bought or sold a used car,
designed a printed circuit board,
done a flood-plain certification,
or worked in a factory.
Yet I have been helpful to people
in all these capacities.
When I was a graduate student,
I thought I might be able to run my own business.
I designed, patented, manufactured, and marketed
a phonograph tonearm for high-end audio systems.
I learned enough about machining
to build two or the four prototypes
in the Stanford machine shop.
The LOCI tonearm
was terrific sounding,
great looking, very innovative,
and not a financial success.
I learned that there is a lot to running a business
besides sounding terrific, looking great, and being innovative.
I come to work
with a healthy respect
for the people doing real work.
My contribution to mankind's existence on this planet
is making these people able to do more.
It is the people who make things,
who move things,
who put things together,
and who install those things
who create wealth.
The rest of us are along for the ride.
A friend of mine showed respect for these real-work people
when he said, "If you don't ship, you're overhead."
If you're going to be overhead,
then add value to the people who are not overhead.
There is an old generation of "academic people"
who study intellectual pursuits and teach students.
While some of those students become academic people,
others take their knowledge
out into the world and
use that knowledge to improve
the work of making, moving, and installing.
Many members of the academic community
lack respect for the work that pays their way,
but many professors and research laboratory engineers
understand the importance of contributing
to the work of making, moving and installing.
There is a new generation of "process people"
who create project plans and documentation.
Much of this planning and documentation is
for work that the process people,
themselves,
do not understand and do not care to understand.
When a few dozen process people get together
to decide how I ought to be doing my work,
their contribution should be measured
in how much more is accomplished
by the people I work for.
They are twice removed from actual work.
While I produce plentiful computer software
and acclaimed decision support systems,
their value is measured in the uplift
of wealth produced by others,
in my case,
in the telephony, airline, hotel, used car,
flood plain, printed circuit board, and manufacturing areas.
I used to tell people I was a mathematician
or an engineer or an analyst or a programmer
or a computer scientist or a consultant
and all of these elicit stereotypes whose
mold I just don't fit.
I'm not sure that the term "industrial mathematician" fits,
but at least it avoids these stereotypes.
I'm not a mathematician.
Over the last two centuries,
the role of the mathematician has been increasingly
an academic one.
The mathematician explores the universe of axioms and theorems
and teaches college and doctoral students about that universe.
If there was a time when the primary role
of a mathematician was answering questions
to make industries run better,
then that was a long time ago.
Today, they produce papers for publication.
I'm not an engineer.
People who design new technologies are engineers.
They typically work in labs with sophisticated equipment,
creating, building, and testing new things.
I have done this kind of engineering
in my hifi hobby,
but little in my professional life.
I'm not an analyst.
Working with pencil and paper,
and perhaps a few computer tools,
analysts primarily produce papers
for production rather than publication.
I have done this kind of work on several occasions,
but my primary medium has been computer software
rather than expository presentation.
I'm not an programmer.
The picture of the computer programming profession
has changed in the last forty years
from a mathematically-knowledgeable expert in computing
to a person who carries out the specific instructions
of an engineer.
Then and now,
the programmer is carrying out the vision of another
while my software is written to support my own vision.
I'm not an computer scientist.
By the time the term "computer scientist" was invented,
I had already figured out I was not really
part of this crowd.
The computer scientists seek a holy grail of computing,
a unified theory of problem formulation and algorithm coding
that brings engineering insights to software fruition.
I believe that traditional methods from 1970
work as well as anything since then
and the same effort would be better spent
writing better software.
I'm not an consultant.
While my job title has had the word "consultant" in it
and I have even worked for a small consulting company,
I work best when my role is closer to the work
than a vendor can be.
Once a relationship is formalized
and deliverables are planned in advance,
my ability to find and do small jobs
that make big improvements is diminished.
Over the last few decades,
consultants have mutated from being mostly excess baggage
to being costly parasites in American business.
There was a time, as I recall from my youth,
when
the frontier was rugged,
the going was tough,
and programmers were real pioneers
surviving on a rugged, frontier diet
of Hostess Twinkies and late-night Chinese food.
The computer center was a special place
inhabited by a select few
who could think in binary, octal, and hexadecimal
and who could sit at a keypunch all night
thinking deep, programmatical thoughts.
From 1955 to 1975,
these people built the software and databases that run
our financial systems,
our bookkeeping systems,
and our communication systems.
At the top of this rugged-frontier, tough-pioneering pyramid
were the decision specialists who could program a computer.
They were mathematicians, engineers, analysts, programmers,
computer scientists, and consultants,
and they were the real thing.
On the glamorous end,
they wrote the software that got spaceships to the moon.
Less well known
were the huge optimizations for selecting oil well locations
and the small analyses for planning factory work.
Along with the scientists and technology engineers
was a team of computer geeks
building the decision support systems.
As I have said
elsewhere,
once the financial, bookkeeping, and communication systems
were in place,
the true value-added of the digital computer
has been better decisions.
On the one hand,
the computer community has been obscuring this basic truth
in building tools such as Microsoft Office
to simplify, and to "dumb-down,"
documentation, visual presentation, and data organization.
On the other hand,
there is a growing community
of charlatans
riding the gravy train
of the computer's association with smart decision making.
A generation later,
the descendents of these charlatans
actually seem to believe
that what they do
is useful decision support.
A host of simplifying and dumbing-down tools
has grown up around this pseudo-technical community
in the form of
simulation, animation, and project-planning packages.
When a gang of consultants
works hard to build an animated simulation
instead of working hard to figure out
what the mathematical models should be,
I don't know if they're sincere,
but I do know they wasted somebody's time and money.
I am the descendent of those pioneers.
I have come to think of myself as the final descendent,
the last of the buffalo
one life away from extinction.
I really do mathematics in an industrial setting.
10:12:03 Mountain Standard Time
(MST).
13347 visits to this web page.