Cross Border Journal

Do Not Take Your Vendor For Granted

If you are a company working with a vendor on a project or on-going basis, the best way to get them to "go the extra mile" for you is to follow this simple formula:

Constructive Criticism (when things go wrong) + Prompt Praise (when things go right)

The surest way to ensure a drop in effort from a vendor is to a) issue petty complaints at every challenge and b) fail to recognize achievements, no matter how small or expected. I have seen these mistakes time and again during my +10 years of working on various types of projects and its a shame.

Supply Chain IT Implementations and Hardware: Lessons Learned

In my 2.5 years with Manhattan Associates, I have had varying involvement with the hardware upon which our software is installed and implemented. So far, I believe that the major issues around hardware fall into the categories of procurement, performance and maintenance. Since procurement essentially precedes performance and maintenance, it is only common sense that the poor procurement of hardware can result in downstream performance and maintenance issues.

Hardware does not necessarily always equate with servers and data centers when implementing supply chain execution software. With warehouse management systems, for example, it is common to also have some form of picking technology, such as RF guns, voice-picking devices, pick-to-light devices, etc. as well as a variety of material handling equipment.

Hardware Procurement

On the projects I have managed or worked on so far, below are the common problems I have seen around hardware procurement:

• Indecisiveness around the overall hardware strategy--do you want to go with an in-house data center or proceed with a hosting solution (outsourced)?
• Indecisiveness around the type of platform to procure (i.e. OS upon which your application and database will run)
• Insufficient research and analysis around the true costs of a particular hardware decision in relation to the requirements to support a particular application, or set of applications
• Lack of knowledge about the operations the hardware is intended to support
• Insufficient planning around the future hardware requirements and the scalability of the short-term hardware sizing (i.e. memory and disk space capacity, chip set constraints, etc.)
• Lack of proper hardware expertise being available to participate in the procurement process
• Poor internal processes for executing hardware decisions
• Lack of planning considerations around the need to procure hardware and services from overseas sources

All of the above can have a detrimental affect on:

• project timelines,
• project costs, 
• execution quality of an implementation,
• vendor relationships, and
• the quality of downstream hardware activities.

Hardware Performance

Usually performance problems occur when the size, volume and volatility of operations is not properly researched and analyzed prior to hardware procurement. Due to the lead times involved in adding hardware capacity, the failure to size properly for operations can lead to devastating consequences after a operation has transitioned onto new applications, goes "live" and quickly ramps up to normal business transaction levels.

Hardware Maintenance

Without sufficient expertise internally to properly maintain hardware, such as needed for monitoring capacity utilization, applying patches and updates, configuring scheduled jobs and processes, fixing  and troubleshooting devices, etc., some companies are forced to deal with costly mistakes and unforeseen downtime or rely on subcontractors without proper knowledge of, or commitment to, the business.

*********************************************************************************************************************** 

My opinion is that hardware doesn't have to be hard, but as my boss remarked once: "If it was easy, it would be called easyware." From working with a variety of companies and hardware scenarios on multiple projects, I can understand how companies end up underestimating either the complexity of the hardware architecture required or the complexity of the operations that must be supported, or both. As a result, I believe companies should educate their employees about the role of hardware, especially how those executing business operations can lend their expertise in determining hardware requirements. Never assume that a particular IT organization, group or individual has everything under control.

Bangalore Calling

I am in the process of finalizing an April trip to Bangalore. One or more of my Australia colleagues and I will engage in testing with our India colleagues in support of the TMS implementation I currently manage. Although I have spent a good amount of time with the India team on the WMS side, it will be my first time with the TMS India team and I am looking forward to the opportunity. Nothing beats being on-site with the technical team as they go through the development and issues related to an IT deployment half the world away.

My wife and I also have a friend in town and so blogging is much lighter than I anticipated with so much going on. The list of articles I have wanted to comment on is growing fast...

TMS vs. WMS Implementations

My brain needs a recharge this weekend before I can jump back into the ongoing topics I am covering around globalization and the impact the U.S. stimulus will have on supply chains. I am in the middle of getting my head wrapped around implementing a Transportation Management System (TMS) versus a Warehouse Management System (WMS). Because we use a common implementation methodology at Manhattan, most of the key tasks and milestones remain the same. The differences become clearer in the following respects:

• WMS implementations focus on the nodes (warehouses and distribution centers) of a supply chain
• TMS implementations focus on the modes (land transport, ocean vessel, airplane, railway, etc)
• The organization and culture built around a these two distinct products tend to be different
• TMS is more network oriented and outside the four walls of a warehouse or DC, driving very different rollout considerations

Although I worked relatively briefly for a 3PL transportation provider in Japan, managing this implementation is really starting to ingrain in me the key pain points for a transportation provider and how systems should be built to manage those, if not completely eliminate them.

What is particularly exciting is foreseeing the point where I can begin to more fully understand the integration points between a WMS and TMS in providing a more total solution for a customer's supply chain. I already have a conceptual feel for what is required in this integration, but to actually develop the ability to successfully and competently create and execute an implementation that seamlessly integrates the modal and nodal aspects of a supply chain is someting I look forward to achieving.

Global IT Deployment: The Framework Overview (II)

Several months ago (has it been that long?!) I kicked off a series of posts on the development of a global IT deployment template, or framework, highlighting the need for the following components as the foundation:

1. An innovation and relations 'hub' grounded in a community of practice subscribing to the OODA Loop philosophy
2. A configurable set of agreed-upon modules that plug into the innovation hub

From my experience, the modules should not be so detailed as to become unwieldly, so I suggested previously they include Financial, Software, Hardware, Infrastructure and Human Resources management. Activities that occur in each of these areas during a global IT deployment would interact with the innovation and relations hub to provide feedback on lessons learned from ground operations and later apply new rules or best practices spearheaded by the team's or firm's innovation leaders.

  

This framework really begins to benefit a global IT deployment once it goes 'online' across the world at each site scheduled for implementation. Regardless of which order a particular site is expected to execute the implementation of a particular technology, bringing all sites online from the start will ensure the following:

• Preemption of critical issues
• Gradual reduction or complete elimination of repeat issues from site to site
• Gradual increase in team efficiency, productivity, innovation and overall learning and performance

The above obviously leads to increased customer satisfaction as lead times decrease along with costs. This develops into strong references and an increased potential for future return business on other technology investments and deployments.

When multiple sites come online, usually headquarters, or the office where the deployment deal was initiated, becomes the 'lead hub' as show below:

Imagining this from a user perspective, each person in their respective areas of responsibility (the modules) would have access to an interface where they could reference and utilize such resources/tools as:

• deployment guidelines as currently established
• critical issues previously dealt with or under consideration
• risks and opportunities to be aware of
• outside news and internal commentary feeds related to this specialty
• deployment team profiles and video introductions
• secure web conferencing via voice/chat
• deployment-specific document libraries
• language-translation capabilities

In addition, everyone would have access to an innovation/relations interface to see the most up-to-date changes, best practices and rules being put into place to make the deployment a success. Project managers, regional and local, would manage the overall access to this interface but the idea is that all participants on the deployment would have real-time access to a deployments developments as it moves from site to site. This can only serve to eliminate the inevitable 'reinventing the wheel' or 'repeat instruction' scenarios that cost valuable time for project managers and resources alike when sites are brought into the picture only slightly ahead of ground implementation.

Geographically, a deployment of linked sites might appear as below:

 

As I have hinted above, a user-friendly technology solution is required to make this framework effective. Although there are online solutions already in the market focused on building collaboration amongst project teams, the key is how leadership deploys this technology, the philosophy behind its utilization, and the way in which multiple sites share in the deployment process from beginning to end.

As many experienced managers know, the greatest technology in the world will fail under poor leadership, poor strategy and/or poor methodology.

Reposted: Global IT Deployment: The Framework Overview (I)

I have been sitting on this post for some time as I have been on-site at my client's distribution center, busy with several tasks during the day and working the evenings to synch up with the global team or prepare for the following day. Because this post and the next few are the most important in this series, I wanted to make sure I had some time to sit down and carefully lay out the content I have prepared. Admittedly, I am more deliberate with regards to developing my thoughts and don't mind a delay if I can promise a high quality post.

 

In previous posts, I have discussed the obvious need for a global IT roll-out template and the ideal approach to take in designing and utilizing the template. In addition, I referred to the example of Development-in-a-Box (DiB) as reflecting the approach and principles I have described as the most appropriate for launching a template across a variety of borders and cultures (let's think in terms of office-specific cultures as well as country-specific cultures). However, an approach and set of principles next needs a framework or an organizing structure that lends itself to a rapid launch on a global scale.

 

It is common these days in many businesses to think in terms of "modules" in regards to products and processes. Usually, several modules run on the same platform or logic so that users can simply "plug-and-play" as a module is required. For example, a manufacturing company might pull entire modules from several suppliers to plug into the final product. One of my previous employers, Denso, produced an entirely built HVAC module that could be snapped and screwed into vehicles at customers like Toyota and GM. Boeing has been utilizing this approach to build the new 787 Dreamliner, albeit with supply chain design issues. My own company, Manhattan, takes this approach with SCOPE. As long as the underlying platform--framework--is solid, several modules can be developed in parallel while ensuring they can be successfully and efficiently plugged into the end solution--whether it is an automobile, airplane or software package.

My opinion is that the framework for a global IT roll-out template should take on this modular structure but will be rooted in an underlying foundation built on the principles and approach outlined in earlier posts. Simply illustrated, I have created the below diagram to generically outline the framework:

 

    

In this diagram, the center pentagon is the foundation upon which the modules will plug into. These modules will be driven by a "community of practice" with similar principles and an adherence to the OODA loop concept. This is the most generic form of the template.

 

To move beyond this, the next step I would like to make is defining the core modules themselves, including the foundation in a more universally usable manner. When doing this, I referred back to the supply chain architectures outlined by Dr. Cavinato and extensively discussed in my post on the FAR Matrix (Flows-Architectures-Resilience Matrix). Reading that post would not be a waste of time before reading further. However, to quickly refresh memories, the five supply chain architectures are: physical, financial, informational, relational and innovational. As a result, the illustration above takes on the following evolution:

These modules are pieces of the framework that those from any country can relate to and thus allow this framework to bridge easily across borders and cultures towards synchronizing multiple, decentralized implementation teams.

 

In my next few posts, I will go through each module and further explain their relevance to the global deployment of supply chain technology. I will also discuss the in-module categories where rule-sets could be established in order guide such a deployment, which is typically a longer, strategic initiative. The extended duration of such initiatives naturally means that maintenance of the global design will be strained, and the global team likewise strained. The global IT roll-out template I am putting forth is not only an essential tool in maintaining the core intentions of the global design, but also a tool able to cultivate an environment of innovation, while easing the strain on the global-level project team.

Reposted: Global IT Deployment: Principles to Remember

In my last post I discussed the tone to set in rolling out supply chain technology on a global scale, that the implementation team must have an ingrained sense of the OODA loop in order to develop and build roll-out momentum that is positive and successful. Although the global design that the technology will conform to and the global leadership that initiates the global design must essentially remain consistent, at the regional or local level implementation teams and their traditional methods of operation will vary widely. This is true for both the vendor and client, and I believe an ingrained OODA loop discipline builds bridges to bring these regional or local pieces into synch as a global technology deployment progresses.

In order to create the right tools for a global IT roll-out template, the team developing such a template must take to heart three key principles:

1. Never assume, always verify because...
2. The assumptions you make locally or regionally can kill you globally.
3. The assumptions you make globally can kill you locally or regionally.

Anyone who has worked on global projects likely understands these principles and has probably either met a local manager who assumes the global team has the wrong approach for their country or perhaps a global manager who assumes the local team works by the same practices established in headquarters.

 

It is virtually impossible to avoid making assumptions, but an ingrained sense of the OODA loop allows us to catch ourselves making the most detrimental assumptions. Most importantly, the global implementation team is responsible for doing the due diligence required to sufficiently understand the local or regional environment and be able to bridge the local or regional implementation teams to the global template. At this point, the local or regional implementation teams are responsible for maintaining this alignment with the global template and, as a result, the global design and implementation strategy.

 

Since problems will most certainly arise if this alignment is not in place by the time the roll-out project is kicked-off locally or regionally, the global team must be proactive in providing the information and tools necessary weeks in advance of any local or regional interaction with the client. Likewise, the local or regional leadership must never make assumptions regarding the project prior to synch-up with the global team. I can confidently say from experience that failure to do the above will result in issues that, although not necessarily irreversable, will negatively impact the roll-out and the teams' views of each other in advancing forward.

 

The pieces I will talk about in future posts--rule sets and implementation tools--are the pieces that both govern the development of an OODA loop-driven mindset and allow implementation teams around the globe to successfully work from a global IT roll-out template. But it is important to remember that going into a global roll-out with the wrong set of principles will make rules and tools meaningless.

Reposted: Establishing a Global IT Deployment Rule Set

When working on a project of this nature for the first time, where a multinational company is deploying a supply chain technology solution across its sites around the globe, hindsight is always 20/20. It is easy to say, in reflection, what should have happened to make everything run smoothly. The harder work involves turning lessons learned into new methodologies that can be utilized in future activities so as to not repeat the same mistakes.

 

The process of recognizing mistakes, developing lessons learned, designing new methodologies and putting these methodologies into action provides an ongoing evolution of rule sets upon which to base a successful deployment of supply chain technology across borders. There are plenty of precendents to model this process against; specifically, there is significant research and discussion on the OODA Loop.

 

This concept was developed and formulated by Colonel John Boyd. In a paper online, Fred Thompson describes this concept in simple termsas follows:

 

The first of these steps is observation. Rivals start by observing their positions, the environment, and their opponents. Next, on the basis of observation, each orients itself to the situation and then decides on a course of action. Finally, each puts the decision into effect; that is, it acts. It checks to see if its action has changed the situation, and the series of steps or cycle starts anew (see Figure 1).

This process is neither sequential nor finite--it is a dynamic process that has been elaborated upon by many authors, from different perspectives:

• Article series by tdaxp
• Post by Phatic Communion(Curtis Gale Weeks)
• Presentation "Certain to Win" by Chet Richards Download certain-to-win.ppt

In this blog, I don't like to dive deep into theories beyond making reference to them in detailing their applications and use in real-life scenarios that will make sense to, for example, technology implementation managers. The key here is that the OODA concept can act as the foundational approach to a global IT deployment; it should be ingrained so deeply in the minds of the implementation team that it drives subconsciously the continuous improvement and adaptability of strategy and tactics throughout every phase of a project--sales to support, support to upgrades, upgrades to support and so on. This is essential to all ongoing workstreams, such as procurement of hardware, hiring of human resources, building of infrastructure, etc., throughout the entire deployment, and more importantly, across borders. Where this foundation has been absent, problems and issues will certainly abound.

 

The more implementation managers ingrain this process into an implementation team, the better quality of rule sets the team will produce towards establishing a dynamic and workable global template. Such a template would not lock an implementation team into a fixed set of practices--rather, it would contain an always evolving set of best practices geared towards enhancing OODA Loop and empowering the full talents and capabilities of the implementation team.

My hope is to use future posts in order to capture the tools and methodologies that could be built into a global template for the deployment of supply chain technology across borders.

Reposted: Rolling, Rolling, Rolling...Keep that IT Rolling!

I am currently acting as project manager/local design lead for the Japan phase of a clients' global roll-out of WMOS, Manhattan's world leading software package for warehouse management. Being the third site of the total roll-out, I feel the whole implementation is like a cattle drive across the American plains. You start off with a decent sized herd, get it disciplined and moving at the right pace. But along the way you are tasked with integrating smaller herds of all sorts, and it strains your ranch hands as you try to keep the new pieces together with the old. You try to use any standard methods you established at the beginning, but there are inevitable gaps along the way. Some locals don't care for you too much; pitfalls are just around the corner ready to throw a monkeywrench into your operation. In the end, it's the team and their experience that keeps the herd together, moving toward its destination. I am basically a ranch hand helping integrate a new herd in my area, but going onto my next task after the whole herd moves on to new country...

Over the next few days, weeks, or months I plan to share some ground-level perspective on the execution of a global IT roll-out and my goal is to utilize these captured thoughts towards the creation of an ideal global, roll-out framework that can be used for any client. Because I still have much to learn in this regards, I look forward to pulling references from various sources to synthesize and further develop such a model.

Highlighting the Challenges of Remote Management

The Wall Street Journal's Career Journal has a nice article on managing teams dispersed around the world, titled "Managers Learn to Bond with Remote Workers." The article directly relates to my recent writing on global IT deployment. The sub-title gets right to the point in saying that "far-flung employees need close contact and clear objectives."

Just as with the scenario of deploying IT globally, the author Elizabeth Garone makes the valid point that "as more companies expand their efforts away from headquarters, the need for managers to understand how to oversee remote employees is becoming more critical. Increasingly, managers of distant employees need to get up to speed on their own."

As I have explained as part of discussing my global IT deployment framework, Ms. Garone includes a nice quote that emphasizes the importance of having the right approach and combination of tools in keeping a dispersed team in synch (comments in parentheses are mine):

"Communicate each person's role and business objectives regularly, and establish agreed-upon ways to resolve conflicts and solve problems early on (framework and best practices), says Mr. Eicher. Find out how technically savvy your remote employees are -- and get them trained in technologies (tools that enable and help to strengthen the framework) you plan to use to keep in touch, he says. Remote employees should be comfortable with voice over Internet protocol, or VOIP; video streaming; and instant messaging."

The article goes on to expand upon how to strengthen relationships and these suggestions complement and in some circumstances repeat what I have written earlier. Overall, the article clearly illustrates the value of having in place a framework when engaging in a global IT deployment.