By Kevin Glynn, VP and CIO, DSC Logistics
Software is easier than ever to develop and maintain, so why be stuck with inflexible packaged software? We’ve been told that packaged software is better…that the robustness of a package is superior to what can be developed in-house…that the maintenance of homegrown software is costly…that companies can’t develop new innovations in their software fast enough. That might be all wrong.
It’s never been easier to develop, maintain and innovate “in-house.” Modern software development methodologies, such as Agile and its progeny DevOps, make it easy to focus teams and get quick results. Mobile app design and techniques encourage everyone to concentrate on usability and creating beautiful interfaces. Cloud architecture facilitates easy project starts with both speed and scale as needed.
At DSC Logistics, we develop software in-house because we believe that our industrial engineers, operators and software engineers can be more creative and competitive versus if we used packaged software exclusively. Our ideas are real world tested, in our logistics centers and transportation groups. DSC is not unique; most companies have a similar core group that thinks constantly about the business model and how to improve it. The best thing about this approach? It is fast. Our company controls the pace of change directly; we don’t wait for consultants to analyze the problem, or software companies to develop new versions.
"Packaged software’s big weakness is the reliance on “versions."
An unsung benefit of developing in-house is the ability to release one feature at a time. Not only does the focus of releasing one feature help ensure quality and timeliness, users can learn one new feature easily with little to no change management required. Experience shows that giving users a bundle of features can confuse them, cause unnecessary workplace stress or, more likely, limit the actual utilization of new options available to only a few. That’s a big waste, not only of development time, but also in priority setting. If the users don’t use a feature, why develop it? Keeping things simple and in a tight priority helps employees, customers and vendors all understand the latest enhancement, and they don’t have to invest large amounts of time learning a whole new version.
The single feature development is the killer advantage over packaged software. When a new version is introduced within packaged software, it is packed with other attributes that the software company believes are important. However, the user can’t collectively learn all the new features, and many aren’t even relevant to the business.
Traditionally, the big argument against in-house development is the cost to develop, then maintain, it. But, with the ability to scale endlessly using cloud infrastructure, and some discipline in the software development cycles, the time to implement can be equal to, possibly better than the difficult large scale project called, tongue in cheek, “software implementation.” Support is also becoming easier for in-house developed software; the DevOps model forces everyone to attack weaknesses and write functional, maintainable code. It makes sense to keep support within the company if the software is part of the business model. An in-house support team will react better and faster, and have more empathy for the users and customers, than any third party software company’s service desk.
Package software still has a place in a company’s portfolio. Non-mission-critical systems or those that have no impact on the business model are well suited for packages. Most companies already made heavy investments in financial and other modules within ERP, and it would be a waste to try to rewrite those in-house. Equally, there are plenty of financial and HR packages available, email options and so on.
Packaged software’s big weakness is the reliance on “versions.” Software companies work diligently to produce short-lived new versions with many features, functions and performance improvements versus the prior model. As soon as customers get the new version, they begin to modify it to meet their business needs. Modifications away from the standard package are crucial for a company – their unique business model can never be 100 percent reflected in software designed to work in a standardized way across many diverse enterprises. However, any customization away from the standard package makes it very expensive to move to the next version – the mapping exercise, both functionally and technically is time consuming, often requires expensive consultants and ultimately yields little value for the company. Bluntly, upgrades rarely have a positive ROI.
Software companies are filled with people who write code – programmers, not operators. Software engineers are talented, smart people, but rarely have any of them worked in a factory, warehouse or logistics center. They simply haven’t experienced the world of manufacturing, distribution and logistics. At DSC, we believe that putting our operators, industrial engineers and software developers together overcomes this problem.
Digitizing a business is an in-house activity. The speed we all need to react to customer demands won’t fit into the development cycle of a third party package. By building in-house, not only can we match the speed that customers require, we can also create exactly what the customer really wants. Iterative, agile approaches stress working with the customer to build something that meets their need; this makes us better – and hopefully more important – vendors in the eyes of our customers. Equally, controlling development in-house allows for experimentation; we can foster creativity, and then ask our customers if they see it as an advantage. This ability to react to customer requirements and also develop entirely new things for them suggests in-house development is the way to go.
Where to start with in-house development? Start with your business model and the technology to support it. For logistics, that means transportation and warehouse management at the core. Is your software adaptable? Can you easily make modifications? Do you know when you have to upgrade your packaged software – when does your version stop being supported? Then talk to your IT team. They are likely bursting with ideas, just like your line managers and engineers. Sit down, have a candid conversation about how to support the changes you want. Most of all, be confident that your team knows your business and can deliver better than a remote software company can.