Because of my client schedule, I arrived to the session a bit late - but was immediately rewarded with lunch and free soda to lift my spirits. We then assembled into smaller breakout groups, and I joined up with the Transportation Strategies group, led by Dr. Chris Caplice of the MIT CTL Program.

Dr. Caplice helped to facilitate a discussion with about 40 or so Transportation-focused professionals and graduate-level students. The main emphasis of the discussion centered around what companies are doing now to help improve their ‘Recession Readiness’ and overcome Supply Chain Turbulence. From this discussion, and after hours to allow those soundbytes a chance to simmer, I extracted a few key takeaways for myself that I can use with my clients:

1. Those companies who were ‘Recession Ready’ were ahead of the game with regards to their Supply Chain processes and technologies. They did not “have to” implement new technologies to help them communicate more effectively, or control their supply chain costs more tightly. They were already in place, and companies were in a far better position to make operational and strategic decisions that would help lead them through the turbulence.

2. There are a few ‘best-in-class’ companies who are taking a 6-Sigma approach to this recession, and employing a ‘Risk Matrix’ strategy to help them identify Supply Chain Turbulence in the future. I think of this as “Crisis KPI” reporting: taking a handful of mission-critical supply chain metrics that represent the overall health of the business. In my area, this could be something like Equipment Availability, Load Factor, Cost per Ton Mile, or something similar. Companies are using these types of ’signals’ as leading indicators to help them get a jump on any future turbulence.

3. Turbulence is enhanced by Fear. I use the analogy of a first-time airline passenger on a bumpy flight. The passenger is in a heightened state of fear, and may exhibit irrational behaviors because they do not have the history of being been through this before. Fliers with established processes for dealing with turbulence are far more calm, and able to think through the bumps without disruption. I believe organizational behavior is very similar, and those companies with discrete systems and processes in place will handle disruptions better because organization fear is mitigated.

Thinking back through these takeaways leaves me with one clear message: system design and technology helps companies remove irrational behavior (and costs) at the expense of some flexibility. However, most organizations realize that not all flexibility is good. In the case of the first-time flier, this flexibility of thought led them to irrational behavior. In the organizational context, perhaps this is similar to a knee-jerk reaction akin to “the customer just needs it ASAP, ship it Overnight Air.” Having systems and processes in place would help this Customer Service Rep know that maybe ground service would be acceptable (given a hypothetical transit time) or other mode alternatives existed at a lower total cost.

So - driving variability, or fear if you are in an unknown situation perhaps, will help firms identify, plan, and make changes to handle economic turbulence far easier. Designing Supply Chain Systems to accomodate for these types of behaviors should not be overlooked during your implementation or upgrade.

In this video, I demonstrate how to create a load-level audit trail for the DSW Action ‘Disband Freight Movement.’

I’m often asked by clients how they can track changes made to loads by users. The built-in Audit Trail functionality provides a column-level record of data before & after the change. It also records user name, so you can track changes AND have something useful to manage users.

Expert clients will build in these types of metrics into their Load Planning KPI’s, just as you would build in Carrier Accept-Decline ratios for managing carriers.

The version in this demonstration is 7.4.2.

I am also a small business owner, and I am ‘the’ IT guy. That is the key turning point in this equation - I have the power to make changes if I’m tired of doing all the dirty work.

My typical approach has been to do a full hardware replacement about every 2-3 years. I started almost exclusively using Toshiba Tecra’s, but quickly felt jaded after several HD burnouts and extreme performance hits over an 18 month period of time. Think: not a bell-curve, more like a spiral. So, I moved into Lenovo machine thinking this would give me extra space, performance, and longer lifespan. Plus, my anti-virus applications were massive hogs that provided little protection. I was also frustrated with annual renewals, Hijack-This logs, and application incompatibilities. I was spending every weekend trying to clean, repair, diagnose, research the myriad pc-related issues.

So, a little research on my ‘escape’ plan resulted in something possibly even more challenging: move to a Mac. I have always been impressed with the design (first) and the simplicity of use (second). The technology itself was never an issue - because what can you really do with a Mac at work? Macs are for games, kids, and teachers, right? Well, I learned that Macs could run Windows - which meant that my ‘design + ease-of-use’ idea could be supplemented with ‘cross-over’ ability.

A trip to the Apple Retail store was in order. So, I scheduled a business consultation with one of the Apple Geniuses that focus on professional users, and came equipped with a list of questions.

Can I run Windows (or Win-Doze as my colleague calls it) and my business applications?
Can I connect to remote databases, servers, etc. using commercial emulators, ODBC, etc?
Can I access my client’s networks, shared drives, print servers?
Can I control networking / IP config details manually?

The answers were always ‘Sure’ or ‘Absolutely’ - which means to me ‘most of the time’ or ‘if you give up X,Y,or Z.’ But, in this case, the Genius was nearly guaranteeing me interoperability using the virtualization method. It’s like living in two worlds at the same time, design+ease of use+business horsepower.

So - I walked away with a 15″ MacBook Pro with 4 GB of RAM, 300 GB disk, and a 2.53 GHz core duo chip. I chose Parallels over VM Ware (per the recommendation from the Genius) and picked up a copy of XP Pro. Installation and configuration were easy - almost fun to watch the process after years of Windows apps. I was done in about 6-8 hours worth of effort, and ready to head out to the client site on Monday. I decided to bring my PC with me just in case.

All my Win apps loaded flawlessly - FileZilla, Toad, Office, Putty. My Mac found the client networks easily, and finding the local printers was inspiring! This has always been my achilles heel with the PC - having to find printers & the right network on the PC was punitive. My Mac had no problem with this and I was happy.

The client PC Tech guys came down to install Lotus Notes, VPN, and check the AV security software. When they saw the Mac, they immediately said “we don’t support Macs - sorry.” But I assured them it was just another machine running XP & to install it anyway. They wrapped things up & went on their way.

I’ve been using the Mac for about 6 weeks now, with very good results. Probably the biggest disappointment is document compatibility between Mac and Windows. I want to use iWork as opposed to Office, but I find the exporting process to be cumbersome and the results don’t always look professional. Fonts are different, pictures and logos shift, and it’s another step for me to take when I’m preparing lots of documentation. Plus, my clients want Word docs that they can edit in the future and I feel better giving them Word-native documents as opposed to Pages or PDF’s.

It has also taken me some time to get used to the Mac Finder after years of Explorer. I got used to the rigid structure of Explorer, and miss some of that. But, the Finder is ultimately more flexible and robust. Plus, the Spotlight search feature beats the fur out of Fluffy the Retriever version in Explorer. It’s fast, comprehensive, and easy to use (think Google Desktop but faster).

Beyond that - I’m pleased. My virtual XP machine boots up in 20-30 seconds, my Mac just ‘wakes up’. I run the AV software that comes with Parallels (a Kaspersky product - very strong stuff) and nothing on the Mac. I feel I have the right balance of design and performance, and have really done nothing beyond what I did during the initial setup period.

So, if any other fellow road-warrior consultants out there are tired of Win-Doze - schedule some time with a Genius. There are alternatives.

Here is a summary of the scenario or business requirement - Give us (the client) the ability to replicate our standing orders daily without a feed from the host order management system. These orders always go from the same origin to the same destination, and often have the same pickup and delivery time window.

And my approach - First create an ITEM:COMMODITY that will represent the ‘generic’ commodity. You can also utilize an existing ITEM:COMMODITY if that makes sense as well. Then manually create the Static Order template in the Transport Order UV (or Transport WEB) with the following properties:

Assign this ‘template’ order an Order ID with some logic behind it (ID must be unique, e.g. SYSDATE+ID+ORIGIN_LOC_ID)
Assign the order to the correct SCHEDULE
Assign the order to a specific ORDER GROUP (e.g. STATIC)
Flag the order as UNALLOCATED
Give the order the appropriate PICKUP and DELIVERY WINDOWS (use your own EA,LA,ED,LD logic)
Set the appropriate ORIGIN and DESTINATION LOCATION
Enter the generic ITEM and appropriate QUANTITIES for this order
Save / commit to the database

Okay, that’s most of the base-data setup that you will have to do. You will setup one order template for each unique ORIGIN:DESTINATION combination (or maybe multiples, depending on your business situation). Next comes the ‘customization’ piece which will require some basic DB code development.

At a high-level, you will want to select only the STATIC orders (either select GROUP_NAME or some other ‘tag’), and only orders that are NEW or UNSCHEDULED and make a copy of each. The tricky part of the copy is likely the Order ID - being able to easily generate a sequential counter to apply as a prefix or suffix to the ord.id field would be very helpful. At the same time, apply some ‘constant’ (e.g. SYSDATE) to one or more of the Order Date fields, and map the remaining 3 dates and times against that value. The rest should be pretty easy.

From a business process standpoint, the users will see these Static Orders like normal orders and have the opportunity to consume (schedule) them manually or through an ASD. However, because the orders are ‘tagged’ as Static - they can be queried separately and managed independently of the normal HOST orders. If a Static order is not used within some pre-determined time period, I would update the status of these to CANCELLED, and then run a weekly script to remove CANCELLED orders from the active tables. There are many different approaches that can be applied here, and you can be creative with the flexibility.

The only drawback to using these Static orders is that they are not HOST managed orders. The Transport database becomes the system of record, and therefore communicating order or load information back to other OMS (SAP, Oracle, etc.) or to a downstream WMS could be challenging from a design standpoint. In a nutshell, you will have to find some way to either make these orders exist in your external systems, or figure out an approach that will allow you to circumvent them without negatively impacting business requirements.

So, aside from the tricks to the customization and some fancy footwork on the business process design side - this is a fairly simple and straightforward way to add some very valuable functionality to the Transport application. I encourage any comments, ideas, or other applications of this methodology either here on the blog, or in the forums.

Looking at the RecShip as an ‘Order’ for a specific SKU/Origin/Destination in Transport, we receive a large batch of RecShip ‘Orders’ representing a mix of deployment orders for manufactured product. Utilizing Transport’s deep constraints such as Equipment Capacities, Product-Equipment Compatibilities, Location Constraints, Trailer Capacity Constraints, and others - we were able to generate prioritized, constrained Vehicle Loads and Vehicle Load Lines in Fulfillment that would not have been possible using BTL.

There were three unique objectives that needed to be satisfied during the load building process. The first objective was to prioritize the RecShip based on a combination of the SchedShipDate, NeedArrivDate and AvailtoShip date. This prioritization was customized logic that was written into the interface between Fulfillment and Transport. The logic was different for manufactured items compared to purchased items, and utilized a combination of the Transport ASD and Semi-Fixed Trip functionality.

The second objective was to limit the number of pallets of a specific hazardous material to each load that was built. Third, we needed the ability to build loads with material on partial pallets. The key to this was that the client knew in most cases material on partial pallets would not be not enough to fill a truck. So the load needed to be filled with full pallet material after the all of the partial pallets were added.

This third objective was the key reason that the client opted to build the loads in Transport instead of using BTL. Because any material could be placed on a partial pallet depending on the source, destination, and current sales volume, the material was not the key factor in determining if it was to be counted as a partial or full pallet. Instead, we chose to use Transmode in Fulfillment. Using BTL, we weren’t able to put multiple Transmodes (Partial Pallet and Standard) onto one load. However, within Transport we were able to combine the two Transmodes onto one load - therefore filling a partial pallet truck with full pallet items. We also extended this Transmode logic to some of our purchased items to separate certain groups of items from a supplier into unique loads.

Once the loads were generated in Transport, they were interfaced back to Fulfillment and then to SAP as STOs or POs. Although the client chose to build loads in Transport, we set up all of the appropriate tables in Fulfillment including several tables new to v7.4.1 (i.e. UOMCategoryConvFactor) so that the client would be able to view the loads in Load Manager.

In summary, this was a great example of a joint design and integration effort between two different applications – that actually complement one another very well. I’ll be anxious to work on even tighter integration between Fulfillment and Transport, and also try to streamline the PO/STO create process in SAP.

Thanks to Kelli Sprague at SupplyWeb Solutions for her contribution to this post, and the integration design!

Of particular interest to me are the plans for the i2 TMS with regards to the Manugistics TMS. Historically, these applications have been fiercely competitive in the marketplace. Over the years, each has found their niche - i2 in discrete manufacturing, high-tech, and 3PL markets, Manugistics in consumer packaged goods and retail. The retail niche for the TMS and core SCPO planning applications from Manugistics made good sense for JDA, which was then a purely retail shop. However, i2 brings additional industry reach to JDA that it couldn’t reach from a sales & marketing standpoint.

A recent question from the boards asked - ‘Which TMS will Reign Supreme - i2 or Manu?’ - and I made an off-hand comment about how they would probably both be kept separate because that would cost the most money from a code development and support standpoint. However, this might be closer to the truth than I initially thought. Perhaps the i2 acquisition will serve JDA by improving access to previously closed industry verticals like high-tech, industrial, and service-based markets. Perhaps there will be no plans to integrate functionality of the products, which are already enormously robust applications by themselves in their specific niches. This is what most of my sources are saying - finally, after a month of letting this news settle.

These questions still remain unanswered by JDA and will be a critical next step in the execution of the i2 purchase. The core Manugistics products are already under scrutiny by many buyers due to the large shift away from client-server technology into web-based architecture. This change forces JDA to get existing clients into new versions using technology that requires a substantially different infrastructure - before new clients will sign up for unproven technologies. Keeping the i2 code base separate from the core Manu products will probably be the safest bet until adoption picks up.

Regardless of how this all shakes out, it is still a very interesting move from JDA - and will be interesting to see if they move into other functional markets (Supply Chain Execution for example) in the future. I also have high hopes for the integration of the i2 sales force, which has had remarkable success in selling software (especially the TMS) - which has never been Manu/JDA’s best attribute.

To join the forum, select ‘Forum’ from the Navigation Menu at the top right of this page - or click here.