Last week's Advice Line hinted at a false dichotomy, namely, that in the future IT will need to support business practices instead of business processes. If only the future were so easy -- it won't. Like every previous expansion of IT's sphere of responsibilities, we're going to support business practices in addition to everything else we've been doing, business processes in particular.
The difference is that our history supporting business processes points the way toward our future supporting business practices. All we have to do is recognize the shift. The rest is just a matter of the right package and the good sense to get out of our own way.
[ Find out the 10 business skills every IT pro must master. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line blog and newsletter. ]
IT's ever-expanding sphere of responsibilities
The history of IT is one of scope creep writ large.
First, we began processing accounting transactions. Then we added support for manufacturing, distribution, supply chain, human resources, and other parts of the business, using pretty much the same approach to systems design because they all fit the same paradigm: Present data-entry screens, feed a database by posting transactions, and use the database to generate reports.
Then the personal computer dragged us, kicking and screaming, into the world of unstructured data and human-to-human interaction, where we found ourselves supporting word processing software, electronic spreadsheets, presentations, email, Web conferencing, and (shudder) the telephone system. Worse, the World Wide Web shoved us into face-to-face collaborations with marketing, where requirements change at least every season and not wanting Macintoshes is a character flaw.
Somewhere in there we also squeezed in support for analytics and the data warehouses needed to enable this reuse of the data we'd already helped collect. Compared to how well we support transaction processing, while we've mostly made our peace with marketing and the Web, we've never quite mastered analytics and unstructured data.
It all has to do with the difference between business processes and practices, the latter pointing the way forward.
Business processes and practices
As I've mentioned before, work is organized along a continuum, with business processes at one pole and business practices at the other. Processes are about following a standard sequence of steps, specified in detail, to create repeatable, predictable results. That's what you need for mass production, and it delivers the fringe benefit of making employees interchangeable.
Practices don't make employees interchangeable. Far from it -- while they involve a standard sequence of steps, they're specified only at a high level, not in detail. The details themselves depend on the situation and on the knowledge, judgment, experience, and expertise of the practitioner.
Practices are what you need to deliver customized, tailored, feature-rich, high-value results. You need them even more when your goal is to outmaneuver a competitor -- when predictability is a guaranteed way to lose.
Here's how this connects: Transaction processing systems are exactly what business processes need in the way of IT support. Look at where industry has focused its thinking and it's all there: Business process design has Lean, Six Sigma, Theory of Constraints, and various hybrid methodologies to support it; transaction processing systems have data-flow diagrams, object-oriented analysis and design, services-oriented analysis and design, and normalization standards for data design to support them. Plus, under the hood, we have transaction processing monitors, relational database management systems, and languages designed with transaction processing in mind.
There is no comparable general body of business practice design theory, nor any design methodologies for the kinds of systems needed to support business practices. All we have are special-purpose methodologies and systems tailored for specific practices.
Business practice support case study: Project management
Project management is one of the most extensively developed business practices, both from a methodology perspective, and with respect to supporting software. Let's see what we can learn from it.