It might go by the same name, but today's slimmed-down business process re-engineering bears little resemblance to its clunky predecessor.

Twenty-five years after management guru Michael Hammer popularized the concept of business process re-engineering, companies large and small are at it again -- only this time around with a few significant twists. Chief among them is the re-engineering of the IT organization itself.

Unlike the mega-projects of the 1990s that spanned multiple years and revolved around big, honking ERP systems that cost millions and produced disappointing results, today's process re-engineering initiatives feature multiple, quick-hit projects, many born out of pocket innovation labs within IT.

The methodologies are also different. Forget color-coded Gantt charts and waterfall development techniques. Today, it's all about lean manufacturing, Six Sigma and agile development.

In a nutshell, today's re-engineering is not a one-time event. Rather, it's an ongoing endeavor that involves continually refining and enhancing the hundreds of end-to-end steps involved in developing new products, acquiring and retaining customers, and making money. What it's not about is the software that automates these steps.

"You might re-engineer once, and it takes you from a 1 to a 5 in some area. But the world is changing fast, so what was a 5 quickly becomes a 3," says Daphne Jones, CIO at Hospira, a $4 billion pharmaceutical company in Lake Forest, Ill. "You have to figure out every day how to re-engineer back to a 5. It's a continuous journey."

That's why the savviest CIOs are re-engineering IT itself around those steps with an eye toward creating new streams of revenue and business value as markets advance at hyperspeed.

For example, at Boston-based John Hancock Financial Services, IT team members are organized around business processes, such as order-to-cash or procure-to-pay, rather than around various technology stacks or software applications.

"If you have people organized around the processes being delivered rather than in [technology] silos, that means those people are attentive to how the processes operate and how they need to evolve and change over time," says CIO Allan Hackney. "Re-engineering is constantly changing the status quo."

Customers everywhere are demanding greater mobile access to services, tapping into social networks and showing no signs of a weakening appetite for multiple consumer gadgets. "If you haven't figured out that you have to expose your business rules and processes in new and different ways, I don't know how you'll survive," Hackney adds.

Jones has similarly organized Hospira's IT team around business processes, or what the company calls "value streams."

"I used to have SAP people and non-SAP people, and when someone called from the business, they wouldn't know who to talk to," she says.

Historical Perspective

Re-engineering: Hindsight is 20/20

Michelle Sheedy, a process architect at pharmaceutical company Hospira, has seen it all.

As a former integration manager at Arthur Andersen, Sheedy worked on big SAP projects and other ERP implementations, making sure all of the technology pieces fit together.

"Whether it was SAP or Oracle or another ERP system, if you bought the technology, you agreed to abide by its rules. That was the 'to-be' state. You had decisions to make at a granular level, but those systems were pretty inflexible," she recalls.

Today, as a process architect -- a relatively new and rare title in IT circles -- Sheedy's job is to take an enterprise view of process changes and make sure that a change made in one process or system doesn't adversely impact another. Sheedy, who reports into IT, calls it the "whack-a-mole effect."

"The role of the process architect is to keep an eye on the big picture," she says. She likens the process models and changes she tracks to a library of standard operating procedures that business owners can consult before making changes to their own processes.

For example, Hospira is in the midst of re-engineering its customer complaint process, which is touched by eight different organizations within the company in some way.

"What we're trying to do is make sure the entire life cycle is correctly depicted so that we get an accurate performance measure and that changes made work together and not against each other," Sheedy says. The ultimate goal is to have all of the groups' respective improvement initiatives "move the entire needle, not just their needle," she says.

"As I look back at re-engineering, especially around ERP systems, there would be lengthy projects where you'd set out a 'to-be' state that you could work toward for two years and then find out that's not what you enabled or that it wasn't accurate," Sheedy says. "Today, business is moving too fast for IT to work off of a blueprint that may be a year out of date. That's why re-engineering is much smaller, quicker efforts."