Logistics News: Warehouse Management - Whose System is it Anyway?
Operations Needs to Drive the System; IT Needs to Support and Identify Risks, not Get in the Way
Am I the only one that feels it – this (mostly) unspoken struggle between Operations and IT when it comes to their Warehouse Management System (WMS)?
And I will say bluntly: IT, for a variety of reasons, too often stands in the way of operational improvement in the DC.
Now, this may actually be an issue for any sort of software that doesn't fit in a nice clean box, but since I work in the WMS business, this is where I feel it. I have written often that my theory on execution software like a WMS is that the closer you are to the real moving parts of the organization (like a distribution center), the more flexible you have to be, as a solution provider, to make your solution fit the operation (not vice versa).
Fralick Says: |
 |
| IT needs to realize that Ops is responsible for revenue. IT is in support of that mission. |
|
What Do You Say?
|
|
|
|
It is also my assertion that the best WMS implementations create a platform for continuous improvement. So, why then, when a VP or Director of distribution wants to flex his or her creative muscle and move the system in a different direction, do we sometimes find IT departments standing in the way?
Look, I get the argument. IT is responsible of the stability of the system – its integrity. I respect that. I know there is risk in change and that factors such as risk need to weigh into the decision process.
However, there is a difference between being a facilitator of quality and a bastion of code control and being an outright obstacle. At least once a month I find myself in the middle of small to large squabbles between Ops and IT.
Let me give you an example: We were recently working with one of the most savvy distribution executives around. He had a great idea for a quick modification to his WMS that would dramatically decrease pack time for consumer orders.
What ensued next can only be called a dizzying exchange of heated emails. IT insisted that this mod was not needed, and that they had other changes that he previously asked for ahead of this. When our savvy VP of distribution insisted this had a better ROI and would take little effort, and that would like to shuffle priorities - IT challenged his claims and would not budge.
I found the exchange baffling – isn't the VP of Distribution capable of making rational decisions regarding the functionality of his system? And this with a fairly high level executive. Imagine the troubles mere managers can have it
While there are certainly many companies where there is a very productive relationship between IT and Ops, and where IT gets what their role should really be, I could cite many, many more of these kinds of example.
A Model for Improvement
I have often made my opinion pretty clearly on this topic. I'm with Ops. IT may (often) pay my bills, but in the end I work for Ops. This puts me in the midst of this struggle – but I bring with me a simple method to defuse the situation. I outline my three steps to IT/Ops coexistence.
1. IT needs to realize that Ops is responsible for revenue. IT is in support of that mission. Understand that you, as an IT resource, are supporting Operations, you are not responsible for it. I'm not suggesting letting Ops do anything they want with the system. Tossing mods, willy-nilly, into the system is just going to make a mess of things in the long run. I am just saying that Ops should set the direction of the system, IT should lay out the plan and describe the pitfalls.
2. Ops needs to understand that IT is responsible for system stability. Actually, Ops managers have no desire for instability (they have a downright hatred of it in fact), so IT's role of pointing out issues that will cause instability will (should) be greatly appreciated by Ops. That said, it is important that the processes IT puts in place is in lock-step with the business requirements. Our Agile process (sort of like lean manufacturing – but for software) is an example of how we try to maintain a reasonable development process. This not only makes IT happy, but produces the proper artifacts (documentation, test plans, etc.) necessary to leave the system in good shape while also allowing us to move at the pace required by the revenue generating portion of the business.
While this is not the solution for everyone – it is important to note that the process has to fit the situation. If, for example, we are facing a seasonal problem, and the process to move something into production will take four months, it seems to me that the process is too heavy. Much of the frustration I hear revolves around Ops trying to work outside the process. It is important to recognize that this could simply be a symptom of the fact that the process is not meeting the business requirements.
3. Leave emotion at the door and work this as a business decision. Business decisions are about informed risk, potential ROI, and weighing opportunity costs. Work the three points below, create a list, and let operations make the call.
(A) Informed Risk: Any change involves some sort of risk. The disciplines that IT staffs bring to the table can help mitigate, but not completely remove, risk. IT should seek to minimize risk and inform Ops of the options, if there are any, in approaching any issue. Avoid the pitfalls of over dramatizing risks because of other issues (like workload). I totally understand that most IT staffs are immensely overloaded, but that does not give you license to over exaggerate risk. Ops will just bring someone like me in and I'll have to tell them "I don't know what they are talking about." I don't want to be in that situation, nor do you.
(B) Potential ROI: This should be a quantifiable and IT should work with Ops to correctly define this. Ops, do not over exaggerate this in order to move something you want up the list. In that case, just tell them you want that other thing first. Fudging the ROI just makes you look less than competent.
(C) Opportunity Costs: We probably don't have endless resources or endless budgets. Additionally, we may be sneaking in enhancements between the peaks of business. So, we must weigh the opportunity costs. Doing Enhancement A might mean we cannot do Enhancement B and C. Operations, not IT, needs to make the call and live with it.
Work the business problems, keep egos out of it, and "Don't make me come in there!!"
Agree or disagree with this experts' perspective? Let us know your thoughts at the Feedback section below.
|
