logisticstechoutlook

The Dawn of the In-House Software

By Kevin Glynn, VP & CIO, DSC Logistics

Kevin Glynn, VP & CIO, DSC Logistics

It’s never been easier to develop, maintain and innovate “in-house software”. 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. Don’t get me wrong, 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 rewrites those in-house, particularly if the business is not oriented toward financial services. Equally, there are plenty of HR packages and email options

"An unsung benefit of developing in-house is the ability to release one feature at a time. Not only does this help ensure quality and timeliness, users can learn one new feature easily with little to no change in management"

Packaged software’s big weakness is the reliance on “versions.” These 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. It often requires expensive consultants and ultimately yields little value for the company and bluntly, upgrades rarely have a positive ROI.

To avoid spending money with little benefit, companies tend to remain on the old version, and continue to customize, becoming more entrenched in an old system. The package soon is unrecognizable to the original authors and supporting these alternative versions is expensive, frustrating and slow, assuming that the packaged software provider still offers support on an outdated model. None of this is productive for a company, and no one leaves these events with satisfaction. Worse, the patches recommended have to be tested in the unique customer environment, and that often takes company resources away from current projects. Patches often produce conflicts with the customizations, generating another round of development, testing and consultation. Updating customizations might require going back to the original consultants who wrote the code often not immediately available, always expensive, or worse, not able to be located the software company charges greater than 20 percent of the original list price each year for this insufficient and ineffective support. It is a process that doesn’t make sense when examined objectively.

Of course the major benefit of the “support fee” is the opportunity to get a new version, which is essentiallya collection of the software company’s best estimate about what customer’s need, efforts to stay ahead of the competition and their own vision of the industry. But, why should a company place its strategic business model in the hands of a remote software company? How can they possibly offer a competitive advantage to a single company when they offer the same standardized software to the customer’s competition? Finally, software companies are filled with people who write code –programmers, not operators. Theseindividuals don’t really understand how a company really works. 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 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.

An unsung benefit of developing in-house is the ability to release one feature at a time. Not only does this help ensure quality and timeliness, users can learn one new feature easily with little to no change in management. 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 understand the latest enhancement, but they don’t have to invest large amounts of time learning a whole new version.

The single feature implementation is the killer for packaged software. When a new version is introduced within packaged software, it is packed with new attributes that the software company believes are important. However, as we’ve just noted, the user can’t collectively learn all the new features, and many aren’t even relevant to the business. So, why spend 20 percent of your license fee to get functionality you can’t use, don’t want, or, worse, conflicts with your business model.

Traditionally, the big argument against in-house development is the cost to develop, and 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, possibly better than the difficult large scale project called ‘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.

Where do you start? 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 is confident that your team knows your business and can deliver better than a remote, disconnected software company can.