Hello!!!
If you’re reading this, odds are you’re one of the 5 people
I sent the development website to… but if you aren’t – Welcome. This may become the rantings of a madman, but
maybe not, because I started writing this to keep myself sane as I pass through
the loneliest part of designing a large system…
Designing the System…
Especially at the beginning… it’s extremely lonely because
you can’t / don’t want to bring that many people in. There are many reasons for it:
·
It’s your crazy idea, and you don’t know anyone
else who thinks it’s a good idea.
·
Therefore you have lack of commitment or
enthusiasm.
·
You can’t blame them, because at this phase of a
design… it’s very much vaporware and in your head. Hard to contribute – when you don’t know the
big picture.
·
And it’s sometimes easier to just lay out the
whole picture before you invite criticism (constructive and destructive).
And by easier, I really mean in terms of inviting people in
to help or offer advice. It’s not easy
though to get a big idea out. It’s
mental pregnancy and you only have 10 little digits to get something out that
has gestated for over 10 years.
This system has been brewing in my head since 1997, when I
last worked at a trucking company. There
I went through all the pains and agony of helping that company move from a
homegrown system to an off the shelf system.
I had fortunately great experience going into that project:
·
I had already worked in programming for 3 years,
working ironically on a mainframe, and the first iteration of VB… yes VB 1.0…
and QuickBasic and Business Basic… as well as the VeriFone credit card
programming language TCL…
·
My start with the trucking company was as a
company OTR driver. During that whole
time, I kept thinking of ways to get computers into trucks… and something
better than the emerging satellite systems of the time.
·
I eventually worked in the Fleet Maintenance
part of the business, trying my best there to automate their processes…
·
Got the notice of the management who then wanted
me to learn the rest of the business so I learned dispatch and freight
coordination.
·
Then I was asked – Wanna go into Marketing or
IT? While that may have seemed an odd
question, their marketing guy was a very sharp IT guy with a marketing
background. Also knew EDI extremely well
and had been a leading force in using EDI to help grow a major portion of the
company.
·
But Marketing sounded evil to me (Dad was a
salesman – and I have Daddy issues). So –
I chose IT… which is where I thought I was heading anyway…
From that point on, I became lead on getting the new system
implemented. And it was a train wreck
for a number of reasons…
·
The system was originally designed for LTL
(Less Than Truckload), and we were applying it to a longhaul fleet. (I am to later learn in life when dealing
with AS/400 platforms… this was the norm… Telecom LD systems retrofitted to
handle Local… Local systems retrofitted to handle LD… Either of those kluge systems adjusted to
handle services outside telecom… for another blog)
·
Because of our “EDI / Marketing” guy… we had “non-standard”
versions of EDI with our two largest customers (and they were VERY LARGE
Fortune 500 Companies). The software
company was not prepared to handle this huge variance, and because EDI
constituted 80% of our business… we were in trouble.
Eventually we worked through the reconfiguration and
training (which is how we solved the LTL vs LH incompatibilities). That was the easy part… which in retrospect –was
not that easy.
Solving the EDI issue was the grand mal. It eventually got so bad, that the marketing
guy was no longer allowed to talk to the software company because he threatened
to blow their place up… it was a little extreme, but also clear was that they
weren’t getting the message we were sending them:
We can’t
move to your standards
You will have to modify your
software to handle our standards because this is where the standard was heading
(EDI guy held a prominent position on the EDI Standards Board.)
If you don’t – our business will be
destroyed… and that’s not figuratively…
In a role that I would fall into often early into my career,
I was sent to the software company to soothe things over and resolve the
issue. I was also told – don’t bother
coming back if you can’t because there won’t be any place to come back to…
(I’m only 24 at this point in my life… yeeeeehaaaaa!!!!)
I flew to the software company, and my company provided me a
company car… which was Semi Truck, which I would arrive early and park
obnoxiously close to the front door so they would know I was there. Actually – that’s what I was told to do – and
I loved the idea.
We would finally resolve the issue after many long nights,
and working with their lead architect to show him – let us help you design for
your next roadmap release for EDI. We
just need to do it now.
I was able to return back to the trucking company the hero
of sorts, and there waiting for me was the actually start up… in which I didn’t
sleep for 3 days… (I remember trying to fall asleep, and was afraid if I did… I
wouldn’t wake up).
Thankfully – as mentioned before – I was only 24…
After finally getting this system up and running, I couldn’t
help but be disappointed by it. It
certainly felt like we had spent a lot of money for something that didn’t quite
fit our needs. It wasn’t bad, a number
of other companies used it, but it just didn’t quite work right.
It got even trickier once we installed satellites into the
trucks. It literally locked up the
system in that the system required the driver to report their status, and if
they or the dispatchers screwed something up… you couldn’t re-dispatch the
driver, or move the trailer if had been dropped, but not reported – there was
no way to update it’s location.
Like everything else –we found ways around these issues, but
these issues stuck in my head… and as I gained experience with other systems,
and other design paradigms, I kept thinking – I could totally do that better…
And – if I ever decided to start my own trucking company –
what would I want to run my business on.
Obviously – since 1997, systems, processors, languages,
databases, communications have all increased easily a hundred fold.
But I still haven’t seen a design I like. My experience instilled me with the following
wants (in no particular order and not a full list):
·
A Full Functional In Cab Computer for the driver
with weather maps, routing (with intelligence to avoid hazards like low bridges),
GPS reporting, and integration to Logistics System to provide automated cash
advances, signature capture, Over/Short/Damage Claims reporting, pick and
choose dispatching, or automated dispatching.
·
A Fleet Maintenance System that can support not
only in house repairs, but inventory, off site repairs, provide a directory for
authorized repair centers, warranty tracking.
Again – I also see tablets involved to resolve repair orders, etc
·
A logistics system that can eliminate the mounds
of reports, and flat screens of data, and improve the efficiency of the users
by visually displaying the status of the area they are working on. GIS would be a big part of this picture. This came from my own experience learning
freight management and feeling completely worn out before noon just trying to
get loads set up for drivers coming into a dispatch area… Seeing them visually on a map would tell me –
ok – he’s gonna be on time – I can get him a load set up – and promise the
customer we can pick it up. That’s the
magic of Freight Coordination – keeping drivers and assets moving, and keep
promises made to the customer…
My final want, which was mainly inspired by working with
systems designed for one business model, but applied to a completely different,
is to have a system we can easily configure to a transportation business model. Any business model.
I want to be able to support:
·
LTL
·
Long Haul
·
Mix of LTL / Long Haul
·
Courier Services
·
Bulk Carriers
·
Intermodal
So – how do you make that happen… well… how do you build a
universe? It’s large and complex, but
reverse everything back – and it all starts with hydrogen…
What’s my hydrogen in
transportation? This is ironically a
question that has been grappled for some time since people started shipping
seeds for cloth. And it only became a
question when the scale of shipping grew from oxen carts, to shipping vessels.
The smallest unit is what I call the Parcel Unit. The parcel unit can be anything, as long as
you can define it by weight, height, length and depth. A parcel unit can be 5 tons of salt in a rail
car, or it can be a box of chocolates.
The purpose of any logisitics system is to manage the
movement of that parcel unit, and possibly bill for it’s movement.
Starting with movement, a parcel unit will generally not
have it’s own legs, so we have to assign it to a cargo unit. Again, normalizing a cargo unit, it’s the
inverse of a parcel unit. It still has to
have height, width, depth so we can calculate available volume, and determine
if that parcel unit will fit in that cargo unit.
Now that we know it can – we can assign that parcel unit to
a cargo unit. That becomes an Event,
which is the beginning of our tracking of that parcel unit. Certain events can trigger other events like
billing, or paying operators for hauling that parcel unit.
Which segues into – how do we move the parcel unit now that
it has been placed in the cargo unit.
That cargo unit needs to be given power to move from Point A to Point B. That’s why it’s assigned to the Power Unit.
The Power Unit just identifies what will be moving the cargo
unit. There can be times where Power
Unit and Cargo Unit are literally joined at the hip, like a cargo van, but a
power unit can be a semi truck, a bogey (that piece between two joined
trailers), a train, in the case of ships or airplanes, a combined Power/Cargo
Unit – just like the cargo van – just bigger.
Of course, the final part of this parcel journey can’t even
start without an operator of that power unit to navigate it to point B. That’s where the Operator comes in. The operator is the person or entity
responsible for getting that parcel unit from point A to point B. The operator can be a driver, pilot, engineer
or captain of the power unit. The
operator can also be a separate company who is providing that navigation
service.
Simplified within my system – an Operator is the entity
getting paid to move this entity chain from point A to Point B and an event may
be generated upon completion of that journey to compensate that operator.
BTW – I’m being careful to say “may or may not” get billed
or paid because at this point, the system is still open to be configured to
track parcel units. Some implementations
may just use the system to track movement, where others may use it to generate
billing and payroll.
What enables this is EVENTS.
Events can be configured to say – “ok – this task is complete – go look
up the customer’s contract to determine billing”, and off that same task we can
also spawn, “Go look up operator’s profile and determine payment”
If you’ve noticed through the above description of the
transportation life cycle, I’ve never said, “This is an LTL setup”, or “This is
a Long Haul”, or Intermodal, or marine shipping…
Literally – the framework doesn’t care.
What does matter is the configuration of the “Event”
system. Events are configured with business
rules, which define how the system should operate within that business.
So you have a system that can support a pure Long Haul
company, or pure LTL, or as is becoming more the case – a mixed company, that
may also have Intermodal links.
This is all supported because we stripped the problem down
to it’s basic purpose:
MOVING
THAT PARCEL UNIT!!!
Other things I’ve done to strip down the problem, and keep the
whole thing simple is to take away the question of building an accounting
system. I will not build an accounting
system into the framework, because that’s not the framework’s purpose. But I’ve seen this done on a number of commercial
systems, and it just makes me cringe.
What if I already have an accounting system, or I have a cloud based
system I want to integrate with. What if
I separate payroll provider… What if the trucking part of my business is just
one small facet??
BLECCCHCHCH!!! Thank
you – I’m just shoving that to the side.
Instead, we will provide interfaces to pass accounting
information to and from the system.
Events will determine when to send billing and payroll to the accounting
system, and when the system needs to display accounting information – it will
use an interface to get that information.
We do the same thing for CRMs. We have a “basic” definition of a customer,
enough for someone to manage the customer expectations related to
transportation, but if a business has a CRM, we have the ability to grab that
information, take what we need from it, and populate it into the system.
For both – we provide links back
to the CRM or Accounting systems.
The funny part of what I wrote above was that was not what I
wanted to write, but I think I needed to do that again – for sanity purposes…
have I thought everything through… why did I design it this way… does it still
make sense.
Fortunately – it does.
And now hopefully it makes sense to you.
Further entries in this blog will be my attempt to show where I’m at
with design – and some of the “dirt level” design questions I’m having.
Stay Tuned!
