Selection of a package to handle processes around the business is the norm these days.
The fear of defining tools is great, borne on the back of prior projects.
It’s also easier to show the business a package — “does this come close to meeting your needs?” — than it is to walk through a conceptual architecture and design.
Of course, more than half the time, IT gets presented with a package decision made by the business area, too.
Still, packages are often an uncomfortable fit.
First, in the majority of situations, the business is unwilling to accept change solely “to fit the package”: the original applications, written in house, were designed to handle the way the work was done at the time, and the business still wants the software to model the work, not change the work model to fit a piece of software (no matter how much, financially, that would make sense).
What’s far worse, however, is that an increasing number of business processes are organized on a model of what Sigurd Rinde, the mind behind “Thingamy”, calls “barely repeatable processes”.
Asking the customer service representative to “do what it takes” to satisfy a customer can often mean that although the outcome is measurable as a repeatable event, the path between start and finish is often quite different on iteration after iteration.
It’s composed of reusable components that can strung together in different orders, leaving one out, moving another to a different phase, etc.
Trying to code for all these possibilities creates the very mega-project, with high risk and huge sunk costs inhibiting change, at the heart of the business that the package was supposed to avoid incurring (relative to writing a solution directly).
So what should be done?
Certainly engaging in creating sub-process elements to allow the pieces to be used more dynamically is one thing, although in practice I observe this leads to many partially-overlapping packages being installed. I almost never see bespoke code be created, at a fraction of the ownership cost, alas.
This is a good first step, although for those in both the business and IT who have spent their careers talking about “systems” even this seems decidedly unsystem-like. Still, one must begin somewhere.
In an ideal world, each of these subcomponents would be optimized for cost of ownership. Each could then have its own upgrade cycle — and avoid duplication.
It would be the equivalent of designing a village as opposed to a single-purpose mega-complex.
It’s also the path forward to having different elements operate differently in different locations, yet still provide a harmonious whole.
Some could be cloud-based. Some use elements from existing packages. Some are home-grown code.
All are relatively cheap, on short depreciation windows, and thus easier to change.
Once built, all these parts are small projects when refresh or replacement is needed. So release structures, small teams, and other high-value-add methods come into play.
Finally, doing things this way gets IT out of its current “process myopia”, and seeing the bigger picture of the competitive landscape and how it is evolving.
That makes discussions with the business more fruitful as well.