Technical people are often engineers at heart, and really want to see controlled processes in and around their computer systems. We see source code control, configuration management, and process documentation as ways to manage long term maintenance costs and deliver repeatable, reliable results from our systems.
In the realm of ERP systems, this would seem to be a common and well-regarded mind set; however, the businesses supported by these systems often demand information transparency, process flexibility, and quick turnaround of change requests. After all, the customer is always right, right? So, how can we quickly make changes in a structured way? How can we deliver repeatable, reliable systems while maintaining flexibility?
I often hear of process and/or technology mavens erring on the side of too much control. IT seems to prefer this approach, and I hear it a lot when I talk with folks in and out of my company. Of course, the opposite extreme (no-questions-asked flexibility, without concern for long-term maintenance issues) is a slow-cooking recipe for disaster.
One of my favorite analogies on this topic is my Rosemont Horizon story. The Horizon is/was a medium-sized arena northwest of Chicago, now called the Allstate Arena (but it’ll always be the Horizon to me), and featuring your typical eclectic array of “stuff” every month – rock concerts, basketball games, tractor pulls, wrestling, circuses … good times …
Picture the stagehands at the Rosemont on one hypothetical summer weekend; the Rolling Stones are playing on Thursday and Friday, and need a regular stage with a long runway extending into the audience, as Mick Jagger likes to strut out, jump up and down, and let the crowd hear and see him up close. However, on Saturday and Sunday, there is a Garth Brooks concert, and Garth prefers the wide stage with a lot of space along the front for fans to get up close. This is key – a long runway on Friday, and a wide stage by the next night. Note also that Mick jumps up and down, and Garth smashes guitars – so the stage better be sturdy, solid, and reliable (mistakes [stage “downtime”?!] will cost $$$).
One might erect a custom-built wood structure with tons of two-by-fours and bracing; this will be exactly (to the nail!) what Mick requires, but the weight would be immense (immovable!) and the whole thing would have to be torn down and rebuilt in an afternoon for Garth – expensive and extremely difficult, requiring high skill sets for your stage crew. This is clearly not the preferred approach; generally, you’ll see lightweight, sectional staging that is built up from many basic shapes, quickly assembled into any configuration and taken down again, but rigid and strong when assembled.
Ok, so this is a better analogy for component-based architecture, I know, but bear with me; the real magic comes in the detailed instructions / processes involved. Each of the components are highly engineered, with interchangeable connections and standard “interfaces”. Also – and this is key – there are detailed installation instructions to make assembly quick as can be, and you typically wouldn’t have to maintain a staff with a specialized skill set to put this stuff up. The rigor and process design is implemented at the component level – individual sections cannot be redesigned, but you can mix and match and find the best solution for any particular rock concert / business process. The flexibility comes in when you are interacting with the band manager / business process owner, trying to figure out the best way to provide for their requirements while still maintaining control of the environment.
A well-structured, well-educated process should not mean bureaucracy and delay, it should mean execution speed coupled with rigorous process control and auditability.
This Post Has 0 Comments