Platforms Instead of Process


By Chris Wallace, IT Development Director, Coyote Logistics

Chris-Wallace_office-300x200 Platforms Instead of ProcessWhen a company makes the decision to build software in-house, often a key goal is to develop solutions that more specifically address its own nuanced business needs. After all, as feature-rich as off-the-shelf software may be, it can never really address the fact that we use emoticons 😉 in our purchase order numbers—or whatever our particular business idiosyncrasies happen to be—because the problem with third-party software is that the creators know too little about us and our specific problems. While in-house software might appear to address this, it actually has a problem of its own—we know too much about ourselves and our problems. When we build software for ourselves, we can end up producing technology that is indistinguishable from process. Have a new process? If all of the existing technology solutions are too specific in scope, that could mean the need for a whole new technology or product.


But in an environment where our technology is understood as an investment, software that stands apart from any individual business process offers a good opportunity to add real long-term value. If a technology platform can be reimagined to solve multiple problems—future problems—it can not only provide continued and increased value but also provide richer insight into business needs as users explore it, leverage it in new ways, and request new features. If a mature platform can be identified as a solution, or even a partial solution, a development group can pivot more quickly and respond more aggressively. More value, more insight, more quickly? :-O


Given this, how do we build platforms that our business can use to answer questions and adapt to emerging needs instead of building process and technology tied to a single need? Culture.


First, we need a culture that encourages problem-solving. If employees understand creative thinking as part of their job description and see that multiple paths are open to them, they will explore. Is it possible to drop the cyclops emoticon face o-) into this workflow instead of the standard winky face 😉 ? If doing so could improve my workflow or address a new need, my experimentation has suddenly increased the value of the software.


Secondly, we need a culture that encourages communication. Like a social platform, we want our users to see opportunity, not restrictive process, in the tools. And we want them to share those observations and expose others to the tools. Cultures that support movement of people or ideas across various groups help with this. This means that as technology-based problem-solving increases, so do the number of common colds in the office, but tissues are cheap. And the benefits can be huge.


Finally, the role of technology has to be viewed as a core component of the business. Within your organization, software should generally be understood as a collection of tools meant to facilitate work, not as a set of directives intended to control it. It’s much easier to get a person to ask “What more can this tool do for me?” than “Is there anything this tool can do for me at all?” This of course means that people must be able to access the technology—either directly or through education and communication. Like all good experimentation, the best results come from trial and error and that simply requires time with the technology.


Of course, this approach is not all smiley face emoticons. Our IT organization might risk wasting time building a broadly accessible system that ends up only supporting one use case anyway or lacks clarity. A stakeholder with a known need could be forced to settle for something that does not meet his or her requirements as fully as it might otherwise. However, given best practices in contemporary software development, these issues should be mitigated. You are probably not redefining core business concepts or definitions with each project anyway. You might already be building reusable modular systems. You are likely ditching those 18-month, all-in projects for smaller projects that can deliver in stages and adapt along the way. If so, then you are already engaging in practices that seek to expand the use and flexibility of your software solutions. Now all you have to do is get help from future end users in that goal, and your in-house technology could provide solutions instead of simply formalizing existing processes.


Just like there’s no perfect emoticon :-D, there’s no formula for ensuring that a technology platform will be adaptable and flexible for growing business needs, but given the right culture and conditions, opportunities will certainly emerge.