What do these three things have in common? I need to set the stage appropriately before I explain. Throughout my career, I've always had an interest in understanding why organizations fail to leverage the promised power of software and whether the fault lies with the software maker, the company using the software, or limitations of technology. It is often a complicated mix of all three.
Case in point. A company I worked for several years ago made a six-figure investment in an accounting software package. It was good, but lacked a few capabilities required for our business. We asked the software vendor to add those features but they declined stating they had other requests on their product roadmap with broader applicability first. But for an additional fee, their services team could write custom code to adapt their application to our needs. We wrote a big check and several months later got our customizations.
Life was good, for about a year. That was when the software vendor's next major release came out with new features we wanted. We learned that we couldn't upgrade without rewriting our customizations. Unless we paid to redo the customizations (again and again), our product capabilities would be frozen in time.
We considered custom development as an alternative, but the cost estimates were multiples of what we had already spent. The programming team also required that we write out detailed specifications for our current as well as future needs. We didn't think we could predict future needs and custom developed updates would be cost prohibitive anyway. Budget limitations forced us to stick with our customized off-the-shelf application version and forgo upgrades, relying on manual human processes to address the software's limitations. We became a text book example of a company unable to leverage the promised power of software.
Three laws governing software development at the time prevented us from getting an application designed just for our needs:
Fortunately, these laws are no longer valid. Appian's Business Process Management software has helped turn these laws on their head. The "coding" of applications in Appian is done visually by dragging and dropping components from a library by those who own the process rather than a separate IT group. Development proceeds rapidly and changes take a fraction of the time and effort they used to. With Appian, process owners can let their applications "evolve" and skip writing detailed requirements. Documentation is also no problem. Our BPMS suite automatically produces and updates full application documentation (which also nicely serves as full process documentation).
Appian clients who have taken advantage of this approach include Lehigh Hanson for an order-to-cash process and Enterprise Rent-A-Car for a purchase-to-pay process. Development with Appian is actually giving them a way to gain competitive advantage.
Back to Homer, Scarlett, and BPM. How do I tie these three together? Here's a hint. One of Homer's common phrases and the title of one of Scarlett's biggest movies are frequently heard in traditional in-house software development groups and would likely not be heard if they adopted BPM. For the full answer, you'll need to read my new white paper, "Don't License Another Software Application Until You Read This!"
The old rules have fallen. We are in a new era where application development has become dramatically easier and the rigid nature of traditional software development has given way to a world of "application customization."
Vice President of Solutions
Appian helps organizations build apps and workflows rapidly, with a low-code automation platform. Combining people, technologies, and data in a single workflow, Appian can help companies maximize their resources and improve business results. Many of the world’s largest organizations use Appian applications to improve customer experience, achieve operational excellence, and simplify global risk management and compliance.