Calendar
<<  September 2010  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910
Over the past few months, we’ve worked on several application integrations. And each time we go through this process, I am struck by how every implementation has its own personality and set of challenges. 

In theory the problem of inter-application communication is simple; one merely establishes a standard protocol (TCP/IP, XML, etc.) and then codes or configures an application to use that protocol. 

In practice, however, it becomes a little more complicated; the first set of messages exchanged between supply chain systems always seems to take longer than planned. 

To save you some headaches the next time you plan a system upgrade or implementation, I’ve created the following list of points to consider:

1) Size doesn’t matter for schedule compliance.

During the planning stages it is natural to feel comfortable with a large, established software company and to feel a bit nervous about the execution capabilities of a smaller company. But, be wary. In practice, I have seen some of the biggest industry software providers vary wildly in their ability to hit milestones. 

The amount of time and involvement to complete the task really depends on the complexity of your particular business case and the experience level of the services team assigned to the modification and implementation scope. Minimize and contain this performance risk by establishing test integrations as early as possible in the project performance and create buffers in the schedule before critical milestones.

2) The first integration milestone should be early and simple.

The most common integration problems consist of data format and security access issues. It is usually possible to test basic messaging using dummy data well in advance of the completion of complex underlying functional modifications. Most programmers may grumble about the dubious usefulness of exchanging a simple message header – and corresponding ACK (an abbreviation for the acknowledged receipt) – using dummy data. 

But from a project-management perspective, the exercise is very useful. It tests the readiness for integration of the physical IT infrastructure, the program build and configuration, IT security readiness, and vendor ability to support preliminary testing. 

3) Did you RTFM (Read the Fine Manual)?

Recently, we were testing a simple heartbeat message with a large supply chain software supplier, expecting this to be a routine one-hour exercise at most. We thought we’d see a simple ASCII “1H” character from the host and instead received an XML data stream, revealing an application configuration problem early enough to correct it easily. 

The test manager investigated the problem and found that one of his system configuration team members had not been on distribution for the client’s interface spec and had proceeded with a default standard. So, test early and often, and make sure the whole team has familiarity with the applicable specifications. 

4) No IT security plan survives contact with the conference-room pilot.

Make sure your IT administrator is a participant in the conference-room pilot. I have seen many instances where access-point configuration, firewalls, and other IT security issues have caused problems with data-sharing (mapped drives), database access (can read but can’t write), RF terminal disconnects, and inability to connect to communication ports (the messaging worked fine in development, why doesn’t it work in test?). 

In each of these cases, the project team had been assured that all IT security policy issues were taken care of weeks in advance. Make sure your CRP includes an IT rep who can address and fix problems on the spot. 

System integration is an art as well as a science. Keep these points in mind and you’ll be well-prepared to address the inevitable problems that arise during this phase of the project. 

For those of you who’ve already experienced this phenomenon, tell us about your headaches.

-- Paul

In some recent discussions with a few of my colleagues, we’ve been debating the relative importance of people, processes, and technology that support operational excellence, as well as what ties them together.

Thinking about my recent blog post on “Bubba-proofing” a supply chain execution system helped me frame up my position on the topic.

Recall that you can’t realistically idiot-proof a supply chain execution system or any system, but you must design it so that it prevents Bubba from doing something that may have catastrophic effects downstream.

Stated in a more positive and holistic sense: You have to design business processes that best deliver operational excellence, configure and integrate the systems to support those processes, and then train Bubba on how to use the system and follow the processes correctly.

When all three of these legs - people, process, and technology - are in balance, you have provided the basis for a stable platform for your business.

When any one of these three legs is cut short, the other two must compensate for the imbalance.

When two of these legs are lagging sufficient length, it is even more difficult to balance your business platform.

Ideally, you have enough length on all three legs or room to expand (think tripod) so that you will be able to adjust to the following types of fluctuations and maintain your stability:

  • Variability in end-user understanding and comprehension;
  • A wide variety of exception conditions; and  
  • Spikes in business volume, etc.

Your ability to expand and adjust these legs will also keep you from blowing your budget and help you maintain world-class customer service.

One could argue this analogy and insist that one leg carries more weight than others (i.e., all legs are not created equal), but I’ll leave that deliberation for another time.

I will also postpone the debate on whether the people-process-technology picture is best demonstrated with a pyramid, a Venn diagram, or a three-dimensional figure.

For now, I think is the key question is: “What ties these three elements together?” To answer this question, take a look at the image of the stool and ask yourself, “what are the rungs that connect the legs?”

As you see in the image, I’d like to propose the following:

·        The rungs that connect people and process are training and operational best practices;

·        The rungs that connect process and technology are operational best practices and configuration/integration; and

·        The rungs that connect technology and people are configuration/integration and training.

Perhaps you have other thoughts on the rungs that support your business platform.

How do you stabilize your stool so that it doesn’t wobble or falter under pressure? What are your philosophies for connecting your people, processes and supply chain technology?

 

--David Meyers

I was rummaging around one of my bookcases the other day when I came across Fred Brooks’ software engineering classic, “The Mythical Man-Month.” The book, first published in 1975, is based on Brooks’ experience managing the development of IBM’s OS/360. It succinctly dissects the various factors that can make or break a large software development project. These include:

-        Project planning,

-        Assembling the right team,

-        Conceptual or design integrity,

-        Formal specifications,

-        Team communications,

-        Version control, and

-        Need for common toolsets.

The title theme should be familiar to even those who are way too young to remember a computing era dominated by machines like the IBM System/360. The idea of the “mythical man-month” suggests that you can’t necessarily reduce the time it takes you to complete something by adding resources.

In fact, Brooks maintains that adding too many resources can dramatically elongate delivery times. While some of the examples Brooks cites are certainly dated (e.g. “state of the art” is a 2MB machine with 400KB devoted to its operating system), his central tenets are as valid today as when the book was first published.

Seeing the book invoked two reactions in me. The first was a reminder of just how old I am. The second was to wonder if we are really that much smarter today about how we plan and manage our supply chain system selection and implementation projects than we were back in the card punch era.

Part of me says “yes.” We have the tools, methodologies and discipline to avoid Brooks’ tar pits. We have learned from the mistakes of past generations. But part of me can’t help but marvel at the repetitiveness of some of our mistakes. They must be classics, because people are so fond of them.

I attended a presentation earlier this year on the reasons that software conversion projects fail. The presentation cited an interesting statistic: Approximately 38% of implementation projects led by a certified Project Management Professional (PMP) fail.

One can certainly challenge this number, as it is highly dependent on the definition of failure. But many supply chain systems implementation projects do sub-perform despite employing structured methodologies and project management best practices.

There are many potential causes for failure that are beyond the control of any project management team. Flawed business cases, selection processes and vested internal interests can stack the deck against success. Some projects certainly fall into the tar pits due to project management practices. But others fail despite employing best project management practices.

I believe that our project management tools and approaches are better today. However, implementing a supply chain execution system still remains a very complex proposition for many operations.

So are we really that much smarter today? Do we still pursue the mythical man-month?

-- Tom

At the end of a long day last week, a colleague and I were discussing a scene on a TV sitcom that we had both seen recently. In the scene, a main character is being ridiculed by his family over his advanced degree in cartography.

This discussion got us thinking about paper maps versus GPS navigation and wondering if physical maps are really becoming irrelevant.

Much of the time I would believe so, but I do get an odd form of mild vertigo sometimes when following verbatim the instruction of the GPS unit - like I've given away control to the technology. And sometimes it’s a comfort and a relief to work from a paper map or even stop and ask for directions.

My colleague felt the same, which led me to examine this further from a business perspective. I began to think about whether or not some companies suffer from a similar affliction when it comes to supply chain IT integration.

If you are having issues deciding on the right direction for your supply chain IT integration, here’s an exercise that may provide some insight:

Begin by drawing a one-page diagram that depicts the flow of the following technologies that are relevant to your organization. Use arrows to show the way that you thinkthey should be connected.

 - ERP

 - Forecasting

 - Supplier integration

 - Customer integration

 WMS/TMS

 3PL integration

 - Import/export management

 - Performance dashboard

Once you have your supply chain IT integration map created, ask the following:

-   Are the technologies connected in the real world the way you think they should be?

-   What information is involved?

-   Where are the weak or missing links?

-   What causes the most disruption or error?

-   Do all significant parties involved in the supply chain understand the map?

-   Would everyone draw the same map?

-   Is the map dictating your activity? Are you in control?

Maybe it's a good time for a short cartography exercise, and involving key folks in your supply chain could yield some interesting insights on the best way to getfrom point A to point B.

- Matt

 

Photo Credit: Jimmy_Joe

As I was scrolling around the landscape of supply chain blogs and comment boards recently, I came across a question that really struck me as a sign of the times, especially for those of us who are caught up in the ultra fast moving world of information technology and supply chain software

The question – What are the leading transportation management software applications available on the market today? – while quite straightforward, left me somewhat confused. 

How can this question be answered without more context – international/domestic, modes, host environments, lanes, stops, etc.? You get the picture. Yet, there was no shortage of definitive answers (more than 35 and growing as I write this) to this “swing for fences” type of question.

Considering the growing interest in Transportation Management System (TMS) solutions over the last few years (as I mentioned in a previous blog post), it’s not surprising to see these kinds of questions and wide-ranging responses. 

The best way (or if you ask me, the only way) to answer this question and identify your best options for the right TMS solution is to approach the question from a broad to narrow perspective in the following stages:

1. Assessment – Consider your products, markets, suppliers and customers. What are the freight flows, supporting systems and enabling technologies? How is transportation effectiveness measured today?

2. Supply Chain Strategy & Organization – What are the most effective ways to organize transportation inbound/transfers/outbound? How are transportation decisions made (i.e., centralized, decentralized)?

3. Requirements Definition – How is transportation planned to support your strategy? How will the transportation requirements be impacted by future business changes and external factors, such as global supply disruptions or fuel price increases? Where will the relevant data reside, and what level of timeliness will be required?

4. Business Case Development – Where are the gaps in the current strategy? What is the magnitude of the opportunity to close the gaps? How much investment will be required, and what will it take to maintain the new system?

5. Evaluation & Selection – Who are the most qualified TMS providers to meet your requirements? What are the critical functional requirements and key evaluation criteria?

6. Configuration and Integration – What will it take to implement this new system? What are the critical risks and who will manage them (or how will they be managed) throughout the implementation? What are the critical responsibilities of my organization, the software vendor, and my trading partners?

Add them all up and you’re looking at six stages of planning, each one digging down into another level of detail. And notice where the evaluation and selection of a TMS partner shows up in the sequence. 

Whether you’re a TMS rookie, researching TMS for the first time, or a seasoned TMS veteran, considering an upgrade to existing application versus a competitive selection, the process is the same. It all starts with a clear understanding of the specific modules in play for your particular transportation environment. 

Developing and implementing a comprehensive TMS strategy is not a “swing for fences” endeavor but rather a systematic, comprehensive look at the business requirements, systems support, and operational processes within the supply chain. 

Take this one, one base at a time.

-- Kevin
Photo Credit: DeusXFlorida
As I’ve seen on many recent projects, transportation management systems (TMS) are quickly becoming one of the most sought after supply chain IT systems. It’s also been shown that over the past two lean years, the TMS market has fared better than the WMS market. 

And due to consumer demand, they are coming into their own like a souped up Mr. Potato Head, adding and re-positioning any necessary parts. 

From a business strategy perspective, the perennial factors driving the strong demand for TMS applications are the ability to: (1) reduce transportation spend today and (2) provide more nimble transportation processes as supply chain challenges emerge – whether they manifest themselves in rising fuel costs, resource utilization constraints, global/regional disruptions, and on and on. 

From a technology perspective, there are a number of other factors contributing to the TMS market growth:

Functionality -TMS applications have become robust, offering additional modules that were only supported by niche players several years ago. For example, software for Global Trade Management and Financial Settlement were application markets several years ago, but can now be found in the more robust TMS offerings.

Deployment & Configuration Options – TMS providers have embraced software as a service (SaaS) deployment and service-oriented architecture (SOA) platforms, enabling much more cost-effective and functionally adaptable solutions than predecessor applications.

Upgrade Opportunities – Existing TMS customers faced with functional trade-offs or custom modifications and the resulting costly upgrades now have new options to consider. Many customers are turning traditional upgrade efforts into a competitive bid situation and evaluate the changes in the TMS market.  

Taking these factors for market growth into account, (if you have one) where does your TMS stand? Is it lacking a necessary module, like Mr. Potato Head with a missing nose? 

If you don’t have a TMS, now may be a good time to begin your research. In my next blog post, I’ll talk more about evaluating your TMS strategy. 

You can check back or subscribe to our blog to receive new posts in your inbox or by RSS. In the meantime, let me know if you have any WMS or TMS questions.

-- Kevin
 
 
 
 
Photo Credit: Wyscan 

I read that the recent market plunge of nearly 1,000 points was due to what we would call in the IT world, "user error;" in other words, an error that occurs someplace between the keyboard and the chair.

It’s been reported that a trader entered a "b" for billion instead of an "m" for million in a transaction that likely involved a Dow component, which in turn triggered the plunge.

That made me think about a project I’m currently working on and some of the discussions that we’ve been having. As I mentioned in a previous post about this project, we are upgrading an old warehouse management system (WMS) to a newer version. More accurately, we are replacing the old WMS with a new WMS since the two versions have so little in common; the systems are so different that it almost feels like they are from a completely different software vendor (which they’re not).

So during "future state" design discussions for projects such as this one, one of the team members – sometimes all of them – will say, "what if ‘Bubba’ presses Enter before he remembers to Tab over to the reason code field and plug in the right value? The old version wouldn’t let "Bubba" do that!"

This is the point where we imagine – and try to proactively avert– many of these Armageddon-type scenarios that could possibly cause the walls of the DC fall in and kill us all. (Okay, maybe that’s a small exaggeration.)

As this room is filled with a bunch of smart folks, we know that we wouldn’t do such a stupid thing, but Bubba would. So we are all paying very close attention to the options where we can limit the likely Bubba-caused disasters through proper change control and training, and those options that could really trigger some major systems’ problems and require extreme human intervention to reconcile. The latter really requires us to make the option Bubba-proof.

The bottom line is that you can never make a system idiot proof. As soon as you do, up will walk an even better idiot and prove you wrong. But what we are doing is walking the fine line in trying to Bubba-proof the system as much as possible while making sure that we capture all the key components to affect proper change control.

What has Bubba done to your system lately and what did you do about it?

--David

A few weeks ago on the SCIT Perspectives Blog David Meyers asked the question, "Where do you pick from when all the low hanging fruit is gone?"

This question stems from a WMS upgrade project that David is involved with which is actively seeking to reduce costs even though the operation is already running relatively lean. One potential area under consideration is new technologies – including Voice picking.

Having followed Voice Recognition for years, I believe it is a natural candidate for many WMS upgrade and implementation projects. Its hands-free, heads-up user interface gives it a definite edge over RF terminals. And I appreciate the value it can bring to other activities like cycle counting, replenishments, and putaways.

I’m not saying that it is a fit for every operation and every activity. But I believe it is worthy of becoming a mainstream data collection technology for the warehouse floor.

For mainstream technology, functional fit and usability are not the only criteria – integration and cost play a critical role. The integration landscape has matured with most top-tier and many mid-tier WMS vendors offering direct interfaces to Voice solutions.

As I am a voice technology consultant, I pointed out in a recent Tompkins white paper, Voice-Enabling Your SAP Warehouse, SAP WM/EWM users have a variety of approaches available for integrating Voice within their facilities. There are more application providers and hardware vendors chasing the Voice marketplace. More choice drives lower cost points making the technology even more attractive.

So is Voice ready for prime time? I definitely think so.

Is it there yet? I’m not so sure.

Based on what I hear and see, more and more DC operations are actively pursuing or considering implementing Voice.

However, I still hear a lot of folks saying that they’ll get around to it but not right now. I also know of some enterprises that are pursuing a new WMS implementation or upgrade who view it as a Phase 2 or beyond consideration. So it still hasn’t reached the same acceptance level as RF.

Some of this hesitation is due to critical mass. People feel more comfortable with the technology when they personally know other sites that employ it.

Also, I think some WMS vendors and integrators contribute to this condition. They may actively pitch Voice during the sales cycle. But their implementation folks may view it as another set of tasks on a project plan that is already overcrowded.

Anyone who has been involved in a WMS implementation can appreciate that sometimes it is best to walk on Day 1 and leave the running for Day 2 or beyond. However, I can’t point to any mid-to-large size DC implementing a new WMS that is waiting for Phase 2 or 3 to roll out RF.

Waiting until Day 2 or beyond may not be the conservative bet anymore. If the technology is mature enough to be mainstream, then waiting just leaves the benefits – which can be considerable – to a vague future date.

Installing Voice on Day 2 in an operation that went live, with RF or paper, can be more costly and time consuming than doing it in the original implementation.

Once again, I’m not saying Voice is right for every operation. It may even make sense to wait rather than include it in any specific implementation or upgrade plan. But I think it deserves the same level of Day 1 consideration given to RF, pick-to-light and other commonly employed warehouse management systems and technologies.

Am I overly optimistic in my assessment? Do you think Voice is ready for prime time? If not, what do you see as the barriers?

--Tom

In many of the companies I deal with, the Global Trade Management (GTM) function is placed in the hands of either a small, very qualified team or in the hands of a trusted trading partner: the freight forwarder.

These parties are typically highly qualified to deal in the labyrinth of global logistics. However, the placement and structure of these groups, their relationship to supply chain effectiveness, and the specialized technology tools with limited meaningful integration often don’t work in concert with the overall needs of right product, right place, right time, right cost.

For many firms, now is the right time to evaluate global trade capabilities and achieve a competitive edge. In some cases, upon evaluation, making use of existing capabilities with a re-engineered integration and visibility model is the correct path forward.

More frequently, when this evaluation is coupled with a review of current software solutions, a new platform for GTM is the more effective way to proceed.

Global trade management technology has come a long way in the last few years. Several stable and committed solution providers have delivered on a globally connected vision of the supply chain, offering robust applications that rein in control of the global supply chain and provide broad accessibility.

Their focus has been on meeting the demands of constantly evolving trade regulations while also maintaining a commitment to improving trade financial management and providing meaningful visibility.

Because many of the solutions have their roots in Software-as-a-Service (SaaS), their maturity in stabilizing a low cost of ownership and in handling broader systems integration needs is greater than most other areas of supply chain information technology.

Look for solutions that offer the following:

Export and Import Compliance

Export and Import Classification

Trade Document Generation

Lead Time Assessment and Reduction

Reduction in Duties Paid and Non-compliance

Landed Cost/Origin Management and What-if Assessment

Trade Finance

Supplier Collaboration

Robust Integration with Accounting, ERP and SCM systems

The barrier to deploying GTM solutions is being lowered every day, and the path that yields substantial results continues to become clearer. Read the latest paper from Tompkins (and co-authored by yours truly) on Global Trade Management Technology to explore this topic further, and, as always, I’m interested in your thoughts.

- Matt

 

Photo credit: Mishel Churkin

It’s no secret that Tompkins Associates is a proponent of warehouse control systems. In fact, we have our own WCS that we provide to our integration clients: Tompkins Warehouse Control System.

I bring this up, because a recent client meeting reminded me of how a WCS can open up visibility into warehouse operations. This particular client is using our WCS to implement a multi-phase material handling equipment upgrade. The warehouse management systems' (WMS) interface to the WCS are expected to remain fixed while the MHE changes.

During the meeting, we finished the interface review and moved into a discussion of our operational data screens. As I finished a review of our standard screens, I asked the client team for input on any custom screens or reports that they might need to help them manage the DC. After a period of silence, they answered, "We will have to get back to you on that, since our current controls don’t provide us any data!"

It was a light-bulb-over-the-head, paradigm-shifting moment. Our client team realized that they now had the opportunity to "know what they didn’t know" (i.e., get visibility into productivity and throughput data to help them identify trouble spots and optimize their warehousing and distribution operations).

A WCS provides two important advantages over a traditional WMS/MHE controls integration:

The first advantage is that it hides the complexity of MHE interface details from the WMS. In essence, the WCS provides a uniform interface of data items to the WMS while dealing with the physical interface to the MHE. This was the feature that drove our client to select a WCS for their multi-phase warehouse upgrade program.

The second advantage of a WCS is that it provides real-time data to allow users to manage their MHE and warehouse operations. Although this feature can be provided by traditional controls, it is often overlooked. This operational data visibility is a powerful advantage to any organization (like our client in the story above) that has been struggling with an older low-to-zero information MHE controls system.

Tompkins has plenty of good company in regards to touting the advantage of using warehouse control systems in modern DCs. I recently came across an article that shows how Ikea uses a WCS to support uniform practices across its network of DCs. The article, linked here (http://logisticsviewpoints.com/2009/09/03/ikea-overcomes-warehouse-control-systems-islands-of-automation/), is worth reading for a complementary perspective on the topic.

The advantages of a WCS feed into a topic that is the essence of this blog: the topic of supply chain visibility. Any DC is an important link in the data chain that comprises supply chain visibility (or is in fact the origination point of the supply chain).

Warehouse Control Systems are an important tool not only to manage the DC, but to link the data within the DC to the overall supply-chain IT infrastructure. A well-implemented WCS begins supply chain visibility right in your own DC.

-- Paul