Hello and welcome to the seventh edition of InTransit eq, the newsletter that will be “e”-mailed you on a “q”-uarterly basis. We try to include articles that appeal to our clients and/or our prospects and other friends in the industry.

If there is something you'd like to read in future editions please provide feedback. Of course if you are not interested in being included in our circulation list, please unsubscribe where indicated right at the bottom of this email.

Nicola Williams
Managing Director

Now that Transit Odyssey 1.2 has been released, Transit Computer Systems is looking for companies who would like to form alliance partnerships.

We offer referral fees to supply chain software companies who encourage any of their clients to consider using Odyssey for optimised scheduling.

We offer commission on Odyssey sales to software resellers, whose role would be primarily to introduce Odyssey to potential clients and to close the deal – we would be involved at the Feasibility Study stage and would be responsible for the implementation and ongoing support. Finally, we offer free rental of Odyssey, for a negotiated period of time, to logistics consulting firms for modelling purposes.

Over the next few months, I will be contacting our network of supply chain vendors to discuss possible alliances. In the meantime, however, please contact me if you are interested in pursuing the possibility of an alliance partnership further.

Nicola Williams
Managing Director

My name is Peter Sluyter, and I am a network analyst for a major Australian corporation. I have been a regular Transit user for 10 years. I began using the DOS-based version of Transit , then the first Windows-based version and now Transit Odyssey. I have used Transit in a number of previous roles for a wide range of optimisation functions. My current role typically sees me use Transit for different planning and network optimisation functions, including a recent “service optimisation” project.

Service optimisation is the process of developing the optimum service schedule for a product. This product needs to be collected from a distributed network of collection points, transported to a processing centre for sorting, and then moved through the wider transport network of the corporation. The product has an extremely tight service window to ensure delivery constraints are met across our supply chain. The service window for “collection to first processing” was to be reduced from 75-85 minutes to 60 minutes (with a few distance-related exceptions) in order to add an additional processing step.

Collection points are scattered across Brisbane, with the furthest collection point being approximately 60km from the processing centre. The previous Transit-developed schedule has been running smoothly for a number of years, with only exceptional traffic conditions causing any disruption.

When I was given the task of investigating the new scheduling options I had to ensure we were able to meet these extended service requirements while still minimising costs. I spent a considerable period pondering the best method to employ for this optimisation. Initially, I decided to just run the data through Odyssey without any significant parameter setting or data editing.

The results were disappointing, but it was a start. Analysis of the results led me to make some wholesale data changes to the locations of the depots where vehicles were based. I created a large number of different depots for better coverage of the collection sites and re-ran the scenario. The results were better but needed further refinement. I created more depots and increased the number of vehicles at each of these depots to many more than I thought I would ultimately need.

The results were quite good. Odyssey had selected the minimum vehicles required and had given me the result I wanted. I then proceeded to refine my schedule by exporting the data and modifying the time windows for the customers – my goal was to force Odyssey to use more vehicles so that I had an over-resourced schedule that made the solution more robust in the long term. When I reached a point of diminishing returns (i.e. after this point the addition of further resources made little or no improvement to the schedule) the schedule was ready.

The analysis of these run sheets reinforced to me the importance of asking Odyssey the correct question and providing the information it needs. After all, the system is logical and only works within the guidelines you set it. If you think outside the square when structuring your data, you may make dramatic improvements in your results.

Company restructure

Now that almost all of our clients have upgraded to the Odyssey version of Transit, we are starting to move into a new stage in Transit Computer Systems' life. For the past 4 years, the Client Support group has been part of the “Operations” team, managed by Damian. As well as client support duties, their key responsibilities were system testing and helping our clients upgrade to Odyssey.

From 1 July, the Client Support group is part of the “Business” team, managed by myself. Their focus will be more holistic client services - they will be more proactive in keeping in touch with all our users, to make sure their companies are getting the most from their Odyssey investment. They will also be more heavily involved in our consulting projects; this has the added benefit of facilitating first-hand experience using Odyssey for “real-life” applications.

Scott's promotion

As part of this restructure, I am very pleased to announce that Scott Dowell has been promoted to Senior Account Manager. Scott has been with us since March 1999. During that time, he has held a number of key roles within our Client Support, Quality Assurance, Implementation, Training and Development areas. More recently, Scott has contributed significantly to creating and monitoring the annual operational plans as part of the Management Planning Team.

Odyssey 1.2 has a new function that refreshes the map view to reflect changes made to the schedule. If you change the schedule manually, un-allocate orders, drag trips onto different vehicles, or even turn on/off call numbers, rather than closing and reopening the map to view the changes, simply use the refresh button (the last button on the map view toolbar) to update any changes made.

How is my Help Desk call handled?

When a user calls with a problem, it is logged into our Help Desk database and given a ticket number. An email is then sent to the Client Support team, who contact the user. The response time to return a user’s call is dependent on their maintenance level. Client Support must respond within two hours for clients with “premium” support, within four hours for clients with “standard” support, and within one working day for clients with “basic” support.

We will try to resolve the issue immediately during the call: either via verbal instructions, or by logging into the user’s computer via remote access. If we are unable to resolve the issue immediately, a work-around is agreed upon. We then request that the Odyssey database be zipped and emailed to us, so we can take a closer look. The ticket remains open and our user is given regular updates regarding their issue until a resolution is found or developed. Once the issue is resolved, the ticket is closed within our Help Desk database. We currently have 7 outstanding issues logged this year, from a total of 156 calls - 4 of which we are either awaiting data for testing the solution, or will be fixed when the client gets their Odyssey 1.2 upgrade. Our focus to fix problems is demonstrated by resolving 98% of tickets logged so far this year - so if ever you have a problem, please don’t hesitate to call us.