Building a Better Building

I was asked recently to describe what is the difference between the TLP suite and its competitors, in one easy to understand sentence. I struggled to do this at the time so gave myself the task of thinking about this and coming up with a concise yet meaningful phrase to illustrate differences.

Firstly I started to think about the historical or legacy systems. How would you describe them, what do they do? There are a number of legacy systems out there which, while they have sometimes been upgraded to a new platform, are still  based upon their original architecture and thinking. So nothing has really changed with such systems but I had to give some thought to describing them in simple terms. So what I concluded was;

They help your workers do stuff.

They are to your workers what hammers are to the building trade. They allow your workers to do the tasks they have always done, generally in a way they have always done them. As a better weighted and balanced hammer will provide benefit to a builder, so too will a more functional system provide benefit to your workers.

In effect both the hammer and the legacy systems are transaction processing systems that are focused on assisting workers to execute transactions as quickly and accurately as possible.

My eldest son works in design for a Canadian company that builds houses, carries out major office fit outs around the world and so on. Very large in our terms and focussing on delivering innovative work quickly and efficiently, no matter where in the world this happens to be. I’ve spent much time discussing and observing his work and find it fascinating in that he gives no concern to the need for an upgraded hammer, his concern is on the whole project and ensuring the design will result in less time and cost to deliver. This means having the workers do less, less saw cuts, less nails etc. It also means automating the work as much as possible for accuracy and speed purposes.

So to my way of thinking he works on a business improvement system that is focused on ensuring the business meets client objectives as quickly and efficiently as possible. Transaction processing (wielding a hammer) is a subset of the Business Improvement activity which seeks to minimise cost and increase accuracy in this area.

I think this analogy helps explain the difference between the TLP Suite and the group of legacy systems available to Logistics Companies. So, here goes;

TLP is a full Business Improvement System that uses innovation and fresh thinking to enhance user’s capability to efficiently meet client objectives and grow their business while reducing the relevant transaction processing costs.

There you are, and I did this without mentioning nail guns. Like all such phrases it demands explanation as to how this is done, but I am sure this has been hinted at elsewhere.

Automatic Allocation – Finally

A number of years ago I carried out a loose survey of Transport Companies to see what they wanted, or meant, by the term Optimisation. The survey had been initiated in response to various requests and enquiries for optimisation facilities with these requests largely not defining the problem. At the conclusion of the survey it became obvious that the most common requirement was to consistently make better decisions in the Operations room and to lower Operations costs. It was perceived that many Operations decisions could be automated.

Historically some Transport Management Systems have given some rudimentary form of automatic allocation, generally allocating a delivery to a truck if the delivery is in a certain area. While this has been useful for some it has not addressed all other aspects of the cartage of freight and has not taken into account aspects such as vehicle capacity, contractual obligations, slot times and so on.

The opportunity to be involved with the design and system testing of the newly released Automatic Allocation facilities within the TLP suite has therefore been an exciting time. Can we provide a facility that will meet some lofty goals? Well I’m pleased to report this has been done.

So what does it do, how does it work? I think the easiest way to describe this facility is that in conjunction with other elements of the TLP system a job is entered, company best practice is applied to create the necessary actions (also known as legs or freight movements) required to carry out the job and then allocate each of those actions to the most appropriate run.

From the users perspective they merely enter a job and click the Save button, quite simple really. But those duck feet are really working below the surface with the actions being created, rate cards applied to the job, automatic allocations taking place and revenue being allocated to the runs in accordance with company rules. End result is the runs are being built automatically with visibility of capacities and free space as well as the revenue earned so far by that run.

This sounds fairly simple but there is a lot of intricacy involved. For a start the system must observe contractual rules such as deliveries being made by a certain time. It must also observe slot times available for collection or delivery, handle different dates for different actions and so on. The selection of the run also has complexities such as whether to use a sub-contractor or a company truck, checking capacities, determining whether the job can go on the early truck or must wait for the later one.

This piece of software is a major step forward. It will demand discipline from companies that wish to use it fully but from this they should realise much benefit in terms of accuracy and cost savings. Like all software it will undoubtedly be enhanced over time as the software has not yet been written that is fully finished, however it is a great step forward and sets a direction for companies looking for real improvement to Operations.

Contact us for a demonstration,


Integrated versus best of breed


Discussions have been ongoing over the years regarding the benefits of having a totally integrated system as against a system consisting of various “best of breed” modules. People have different views on this topic but the jury is probably still out on what is the best option. The argument for a single integrated system has been based around versions of that old chestnut “one version of the truth” whereas the other side claim “best of breed” status, even if that has not been established.

Maybe we should look at the actual requirements and work from that to establish the best style of system. So what do we want from our systems;

  • Operational staff to have a facility that is easy to use yet effective
  • Operational management to be able to easily manage their areas of responsibility
  • Operational management to receive reporting that provides a full picture of their area of responsibility
  • Clients and other stake holders to be able to access the system in their area of interest
  • Administration of the system to be as automatic as possible
  • Basic accounting functionality so that customer receipting and supplier payments are managed
  • Accounts staff to have a facility that is easy to use yet effective
  • Management to have easy access to the information they need to manage the various divisions
  • Management to have the information needed to manage the company
  • Accounts people to not upset Operations people
  • Operations people to not upset Accounts people

I am not sure if this is a complete list but it should be enough to explore this topic further.

So what does this indicate, well confusion possibly. Because all aspects of the company are referred to it would be easy to suggest a fully integrated system is the answer. Yet this immediately conflicts with the requirement that Accounts have an easy to use yet effective system. It also conflicts with the requirement that Management are to have the information needed to manage the company. The reason I state these are conflicts is that in my experience (which stretches back longer than I wish to confess) the Inverse Peter Principle can be applied to integrated systems in that;

The sophistication of the Operations modules provided are in inverse proportion to the sophistication of the integrated Accounting modules.

Or if you want me to be blunt, generally an integrated system with a good Operational end has a crappy Accounting end. You do not have to look very far for examples. And the inverse is true, many an international level ERP system has produced rubbish to satisfy Operational requirements. The reasons why are primarily based around focus, software companies set out to develop one thing and focus their R&D budget on this. It is difficult for them to do multiple things in a balanced way.

Best of breed, will that be the answer? In some ways it will be in that Operational people and Accounting people can be happy working away in their islands with systems that are effective yet easy to use. The problem is management at all levels have a tough time as they do not have the integrated information to properly manage their areas of responsibility. Therefore management systems disintegrate into an ever expanding set of spread sheets which cannot be verified and generally cannot be related. At its worst this can lead to a “management by hope” situation which is to be avoided if possible.

The best of breed approach enables us to keep operational and accounting teams happy but creates a problem for management at various levels. This problem is created by source data being entered into various modules and not being available for unified management reporting so the solution is surely to enter all source data into the one module and have that shared with all other modules in a seamless fashion. The solution is therefore to remove the problem. Have all source transactions, creditor’s invoices, stock issues, time sheets, sales transactions etc, entered into the one point and distributed from that point. The logical place for this in a Logistics Company is to have the point of data entry in the Logistics System as that is where detailed Operations Management information is required.

Your logistics system will be processing the sales transactions. If it also processes time sheets, stock issues, creditor invoices and so on this data can be used for detailed Fleet Management, Workshop Management and the management of larger more diverse activities (think of heavy haulage contracts, rural contracting work and so on). The transactions should then be passed automatically from this point of entry to the Payroll and Accounting systems for the processing required in these areas and eventual production of company financial reports. Now management can be happy in that the reporting and visibility they require can be provided whilst keeping their various teams content.

So I suggest the answer to the question posed of “Integrated Systems Versus Best of Breed” is neither. What is needed is a company system platform that is a Cohesive Whole.



Logistics is more than a trip from A to B


It was a few years ago now that an Operations Manager at a significant Civil Engineering Company said to me “When a land slide hits the gorge road I need to know what effect it has re-allocating trucks from contracts to the maintenance work”. I’ve always remembered this conversation as it points out that Logistics is far more than moving a carton of freight from point A to point B, and illustrates the complexity of the problems that the industry must address.

Logistics does in fact encompass a number of elements. The management of the transport fleet in terms of allocating jobs and billing these activities is widely accepted as being a dominant function of a typical Logistics Company. For many however their activities will spread into areas such as Third Party Warehousing, managing the storage and handling of goods as well as their distribution. The management of these goods is also being extended into simple manufacturing tasks, blending raw materials to make finished products with such work often requiring specialist equipment.

In rural areas the Logistics Company can offer a comprehensive range of services to clients, from carting freight of various types, to spreading fertiliser and providing rural contracting services such as hay making and contracting work involving non transport plant such as diggers and graders. These services can move the Logistics Company into areas such as Civil Engineering with the complex operations and accounting demands of such activities. Teams of workers are required, not just the driver, suppliers are not all transport related, plant items do not necessarily run on the roads.

And then you get those Logistics Companies that fill a demand by sourcing products which they on sell to clients or members of the public. Commonly such products are landscaping focussed with Transport Companies in many areas selling product as well as carting it.

Then if you cast your attention to aspects of the Logistics business that are not related to customers but to resources then further complex requirements arise. These are in areas focussed on the management and utilisation of resources, ensuring you have enough resources, but not too much, and that they are able to perform productively for you.

It is enough to make your head spin but is not an exaggeration. I know of many Logistics companies that carry out all such activities described here, some with more. The challenge is to develop the systems and processes that allow you to manage such complexity without resorting to an ever increasing level of staff and without accepting a lowly level of management information.

That is why it is pleasing to note that the people at TLP Software acknowledge the complexity that is involved and are showing signs of doing something about it. Very pleasing in fact, when you consider that many software vendors are “dumbing down” their software as they seek to proliferate using the software as a service model. Odd term that, I often think some vendors think that software is the service so they don’t need to offer any, but I digress.

The TLP Software provides functionality never seen before in a Logistics System, tying all of these loose ends together in a nice simple to manage system. If you want to cart product into stock, it does this from a consignment note as part of the transport process. If you want to cart bulk material to a civil engineering contract, having Operations managed by Transport people and the Contract side by Contract people, then no sweat. The array of such integrated functions is vast and well worth looking at.

I suggest you send an email and arrange a free session with Rob ( to catch up on what this type of system can do for you, the benefits it may bring and the headaches it may cure.

Thanks for reading,



Third generation rating is a must says Trevor Ammundsen


Third Generation Rating

It has taken some time for the IT Industry to understand the real requirement for rating engines but finally the team at TLP Software have got it right, and now we have the first Third Generation Rating system for Transport Companies.

So before we can understand what this means, first we must understand history. So what were the first two generations of rating systems? We will not bother with describing manual rating off the back of a cigarette packet, more of a generation zero really, but will give a rundown of the computerised functionality that has evolved and been used over the past 30 years or so.

The first generation of rating was really based around inventory/distribution systems, because that is what most people bought and possibly what accounts people understood. The concept of the pricing function in such systems is that you had a price for a thing. For example stock code 1234 was priced at $50.00. Worked quite well if you were selling stock items. For Transport Companies this became a bit of a dogs breakfast as they had to invent a whole lot of stock codes for work such as “Bulk Coal from Huntly to Auckland, Bulk Coal from Huntly to Whangarei” etc.  Basically all you had was a messy price list which was hard to administer and demanded that your admin staff manually selected a code in order to apply a price. Prone to error as many people found out.

Surprisingly many Transport Companies are still using such systems and some IT Companies still feel this is a valid solution to the auto rating challenge. We beg to differ

So what is second generation rating? This is an advance on first generation in that the code entered would now point to a rate card not a stock record. The rate card functionality could be quite strong and flexible in some systems so major steps were taken forward with this generation. Other additions were the use of other transport job fields such as zone codes to be used as part of the search for the correct rate card.

The second generation saw some major steps forward taken however it was still based around a code, let us call it a rate code now. Better systems would give some partial form of automation by linking the rate code to the customer so that the need for staff to select rate codes was greatly reduced.

Unfortunately anything that is code based means that you must end up duplicating rate cards to be sure that each rate card will find something to charge. Failure to do so could mean that no charge would be calculated. Duplication is especially needed when charges are of differing types; for example if Customer Fred was to receive special rates from Hawkes Bay to Auckland but standard rates less 5% elsewhere in the North Island and standard rates to anywhere in the South Island then you would generally need to be creating a new rate card for Fred, copying some existing ones, changing them and so on. Leads to a cumbersome electronic rate book.

Another issue with these historical methodologies is that both generations really only provided some benefit if you rated your work after the freight operation was completed as it was too cumbersome to do it any other way. This resulted in bottlenecks and administrative pressures.

The clever chaps at TLP have overcome most of these historical problems by thinking outside the square and not being tied to the old and tired methodologies. So what makes TLP a Third Generation rating engine?

Firstly the necessity to use a code to point at a pricing calculation, be it manually entered or linked to a Customer, is gone. TLP looks at all valid rate cards for a job and applies the most appropriate rate card for that job. Definition of what is appropriate is up to you and is managed by the way in which you set up the rate card.

As a job can change as it moves through your system TLP rates the job every time it touches it. So for example you may enter the job as going from Auckland to Wanganui and it will be priced accordingly. But when the legs are changed to divert the job through New Plymouth the job will be re-rated to reflect the additional work, if it is appropriate to do this.

Another area where codes are no longer used is to represent geographical points. Zone codes including the myriad of dummy zone codes are no longer used. TLP provides you with the ability to use full address matching when rating. For example you can have a rate from Hawkes Bay to Auckland which is quite general. But you could also have a rate from Hawkes Bay to Logistics Consultants, 19 Tarndale Grove, Albany, Auckland. The system will select the more defined rate card as this is more appropriate. This is made available by the feature of full address matching that we provide which promotes flexibility and accuracy.

TLP have coded their system to ensure jobs are rated every time they are touched (saved) until they have been invoiced. Every time a job is rated the most appropriate rate card is used, which may be different to that which was most appropriate last time. This means jobs are always charged so we can use this information, for checking manifest profitability for example, while the job is still in progress.

The third generation is a step forward and offers the Transport Industry more efficiency, accuracy and the potential to lower staff numbers, in certain situations. Why would you not have a look at what it offers.