Building a Supportable Supply Chain Software Stack – Video Interview with SupplyChainBrain
Right now it’s probably pretty apparent whether or not you’ve got a supportable supply chain software stack. If you don’t have one, you might have plans to purchase or upgrade some time in the future. It’s a big investment and you want to ensure your purchase meets your current and future goals. Jeremy Hudson, Director, Client Services at Open Sky Group, sat down with Russell Goodman from SupplyChainBrain recently and explained what supportable software is, what kind of skill sets you might need and how SaaS fits into the picture.
Prefer to read it? Here’s the Q&A from Russell and Jeremy:
Who is Open Sky Group and what space do you operate in?
Open Sky Group is a global supply chain software implementer. We work primarily with Blue Yonder (formerly JDA Software) solutions, implementing Warehouse Management, Labor Management, Transportation Management and Workforce Management solutions throughout the supply chain.
What does it mean to build supportable software?
15 years ago, software was a build-to-suit operation. It was software partners coming in and saying, “I’m going to build you software and that’s your software for the next 15 years.” That process is no longer applicable when you look at the innovation of the supply chain network. You’re seeing significantly more technology and software that has to be upgradable over time. In order to build a supportable software, you need to have software that is not heavily customized. You need to have software that can be supported by a software support team. You need to have something that when someone says, “this isn’t working,” your software provider or support team knows exactly what you’re talking about because you took a standardized approach. To have that, you must be adaptable as a supply chain. You must understand that your processes need to mesh with the software as it is. You need to be very responsible about how you implement that software and how you change that software over time.
If I’m looking for a provider, any number of people are going to tell me “Yes, we can do that.” So, what do I need to know to be able to analyze or determine which provider I should choose?
A large part of this is looking for a responsible partner. Looking for someone that’s not interested in building something that is outlandish. You don’t want to be proud of your customizations. You want to be proud of your lack of customizations. You want to be proud of the fact that you worked closely with the software and the vendor and have a good track record with it. You want a partner that’s going to be cautious for you. The last thing you want is a software implementer or provider that’s going to come in and say, “we’ll build you whatever you want.” That’s not what you are looking for. You want to have something that’s supportable long-term, something you can maintain and support over time.
What kind of critical elements, or skill sets do I need on my in-house support team?
You need smart, operational minds that work well with your IT departments and vice versa. You want an IT department that works closely with your operations. Those silos are very, very detrimental to your project and very detrimental to your solution. You want a solution that both IT and operations can share and support simultaneously.
How does building a supportable software stack mesh with SaaS?
That is something that is absolutely fundamental to SaaS. For SaaS to work properly, you must have a software that’s standardized and supportable. The whole purpose of SaaS is to have a software solution that doesn’t require a lot of hands-on support or customized support. You want a team to be able to come in and support you in a SaaS model. SaaS will only work with a standardized, supportable solution that’s not heavily customized. Something that you can really build your operations to suit versus building the software to suit your operations.
Building an Argument, here. You want to bring in a partner because you think they will benefit your company, but you don’t have the authority to authorize the investment. You take the idea to the members in the C-Suite. What is your argument? What are the benefits?
I think it’s important to evaluate your current level of headaches. If you talk to your operations team and say, “How often is this system getting in your way?” If you talk to your IT team and say, “How often are you plugging holes in that boat? How often are you having to keep this software afloat?” Understanding the impact of your current software solution and how difficult it is support will really justify the cost savings. You want to implement something that can be placed in a SaaS model and be supportable over time by someone outside of your organization.
