A lire sur: http://www.infoworld.com/t/application-development/how-it-can-think-the-business-190421?source=IFWNLE_nlt_advice_2012-04-11
In other words, IT's traditional emphasis on architecting and integrating large transactional systems may not be IT's best way forward. Luckily, that best way forward can be found in much of the way IT already goes about its work.
[ 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. ]
Learning from tourismAn example of the difference between practice and process can be found in the hotbed of business innovation known as the Minneapolis tourism industry. Way back in 1996, when I wrote the IS Survival Guide for InfoWorld's print edition, I related the tale of the Minnesota Historical Society's RiverCity Trolley. Had David Wiggins, who ran the program, paid attention to what business consultants were advising, he would have created a well-documented tour process composed of a pre-defined tour route and a written script for his tour guides to follow.
Fortunately, Wiggins was either blissfully ignorant of what the world's business consultants were advising or wise enough to ignore them. What he did was give each of his seven drivers a stack of interesting materials about Minneapolis and its history. He also gave them the freedom to create their own tours. The tours received rave reviews.
Wiggins might not have known the vocabulary, but he understood the concept: Guiding tours is a practice, not a process. When you need quality, defined as the absence of defects, process is essential. But when you require "excellence" -- desirable features, the flexibility to customize, and the ability to outguess a competitor -- the cookie-cutter predictability of a process is exactly what you should avoid. You need a practice.
The practice-process continuum
It's been a while since we visited the subject of process vs. practice. To refresh, a process is a series of well-defined steps, which, if followed as prescribed, yield repeatable, predictable results. Disciplines like Lean, Six Sigma, and Theory of Constraints are about improving the design of business processes.
A practice, in contrast, is a series of broadly defined steps. How each is executed depends on the situation and the judgment and expertise of the practitioner. There are no disciplines or methodologies for designing business practices.
Think of process and practice as two poles of a continuum. Some business functions favor process -- assembly lines, for example. Others, like project management, are close to pure practice, but there are lots of examples that are partway between.
In IT, most of the work is more practice than process. Whether you're an old-school business analyst, new-school internal business consultant, or a project manager, systems architect, application engineer, developer, and so on, lots of what you do can't be reduced to a recipe that, even if followed faithfully, will get you through the day.
This doesn't mean you should be improvising -- far from it. What it means is that you need to recognize the extent to which you should predefine how work gets done and the extent to which you can't or shouldn't.
Consider a help desk
analyst who receives an angry phone call. She follows the recipe for
calming down an angry caller: Empathize. But that isn't a recipe; it's a
generic recommendation that every help desk analyst applies differently
to every angry or upset caller. See the point?
If not, consider the first step to trying solve the caller's problem: Reboot. That's what the troubleshooting manual invariably recommends, to the point that, even if you explain you've already rebooted three times and it hasn't helped, most analysts will insist you reboot again. Their calls are being recorded for quality purposes (read: absence of defects), and if you don't reboot during the call, they'll get dinged for failing to follow the process. The actual effect is that the caller becomes angry all over again, and justifiably so. The attempt to reduce troubleshooting to a process makes the situation worse, not better.
Supporting business practices: IT's new mandate
Practice matters even more when you want to charge higher prices for your products and services to add margin. Process achieves this only in industries where everyone else manufactures junk, is terribly inefficient, or both. Then the increase in quality that comes from top-notch processes will be visible to customers in contrast to competitors' products.
By now, in most industries, everyone has ridden the process train far enough that further improvements to quality and incremental cost are in the decimal places. Quality is good enough that customers only notice it when it isn't there. To increase margin, you must add desirable features that aren't in competitors' products, and you must find ways to customize what you deliver in response to individual customer requests.
Until recently, that was just my opinion. Now we have quantitative data to work with. In Keep the Joint Running, the weekly column I publish privately every week, 63 subscribers responded to a survey of whether their company's most important core and supporting business functions are organized as processes or practices.
The results: About half of all business functions are process/practice hybrids. Of the rest, core functions are more often processes than practices, but not overwhelmingly so, while internal supporting functions are evenly split.
Also, and unsurprisingly, smaller companies tend to rely more on practices than processes; in large companies the reverse is true, although even in these, about half of the work is accomplished through process/practice hybrids and of what remains, practices are well represented.
Here's the good and bad news. Good news first: Because so much of what IT does is more practice than process, we have firsthand experience with the sorts of tools that are useful for supporting practices -- tools like Visio, various IDEs, and project management software. The bad news: What we in internal IT know how to do is to build or integrate transactional systems -- the kind of systems that support business processes.
But building the sort of open-ended tools useful for supporting business practices? That's a practice, too. It just isn't one most IT shops have mastered. Has yours?
Few internal IT shops know what it takes to build the software necessary to support business innovation. Does yours?
There's a glaring gap between what internal IT knows how to do and what businesses increasingly need IT to do to support the bottom line. To understand (and close) this gap, we have to revisit the difference between processes and practices -- a key, very large difference, especially for next-generation IT organizations.In other words, IT's traditional emphasis on architecting and integrating large transactional systems may not be IT's best way forward. Luckily, that best way forward can be found in much of the way IT already goes about its work.
[ 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. ]
Learning from tourismAn example of the difference between practice and process can be found in the hotbed of business innovation known as the Minneapolis tourism industry. Way back in 1996, when I wrote the IS Survival Guide for InfoWorld's print edition, I related the tale of the Minnesota Historical Society's RiverCity Trolley. Had David Wiggins, who ran the program, paid attention to what business consultants were advising, he would have created a well-documented tour process composed of a pre-defined tour route and a written script for his tour guides to follow.
Fortunately, Wiggins was either blissfully ignorant of what the world's business consultants were advising or wise enough to ignore them. What he did was give each of his seven drivers a stack of interesting materials about Minneapolis and its history. He also gave them the freedom to create their own tours. The tours received rave reviews.
Wiggins might not have known the vocabulary, but he understood the concept: Guiding tours is a practice, not a process. When you need quality, defined as the absence of defects, process is essential. But when you require "excellence" -- desirable features, the flexibility to customize, and the ability to outguess a competitor -- the cookie-cutter predictability of a process is exactly what you should avoid. You need a practice.
The practice-process continuum
It's been a while since we visited the subject of process vs. practice. To refresh, a process is a series of well-defined steps, which, if followed as prescribed, yield repeatable, predictable results. Disciplines like Lean, Six Sigma, and Theory of Constraints are about improving the design of business processes.
A practice, in contrast, is a series of broadly defined steps. How each is executed depends on the situation and the judgment and expertise of the practitioner. There are no disciplines or methodologies for designing business practices.
Think of process and practice as two poles of a continuum. Some business functions favor process -- assembly lines, for example. Others, like project management, are close to pure practice, but there are lots of examples that are partway between.
In IT, most of the work is more practice than process. Whether you're an old-school business analyst, new-school internal business consultant, or a project manager, systems architect, application engineer, developer, and so on, lots of what you do can't be reduced to a recipe that, even if followed faithfully, will get you through the day.
This doesn't mean you should be improvising -- far from it. What it means is that you need to recognize the extent to which you should predefine how work gets done and the extent to which you can't or shouldn't.
If not, consider the first step to trying solve the caller's problem: Reboot. That's what the troubleshooting manual invariably recommends, to the point that, even if you explain you've already rebooted three times and it hasn't helped, most analysts will insist you reboot again. Their calls are being recorded for quality purposes (read: absence of defects), and if you don't reboot during the call, they'll get dinged for failing to follow the process. The actual effect is that the caller becomes angry all over again, and justifiably so. The attempt to reduce troubleshooting to a process makes the situation worse, not better.
Supporting business practices: IT's new mandate
Practice matters even more when you want to charge higher prices for your products and services to add margin. Process achieves this only in industries where everyone else manufactures junk, is terribly inefficient, or both. Then the increase in quality that comes from top-notch processes will be visible to customers in contrast to competitors' products.
By now, in most industries, everyone has ridden the process train far enough that further improvements to quality and incremental cost are in the decimal places. Quality is good enough that customers only notice it when it isn't there. To increase margin, you must add desirable features that aren't in competitors' products, and you must find ways to customize what you deliver in response to individual customer requests.
Until recently, that was just my opinion. Now we have quantitative data to work with. In Keep the Joint Running, the weekly column I publish privately every week, 63 subscribers responded to a survey of whether their company's most important core and supporting business functions are organized as processes or practices.
The results: About half of all business functions are process/practice hybrids. Of the rest, core functions are more often processes than practices, but not overwhelmingly so, while internal supporting functions are evenly split.
Also, and unsurprisingly, smaller companies tend to rely more on practices than processes; in large companies the reverse is true, although even in these, about half of the work is accomplished through process/practice hybrids and of what remains, practices are well represented.
Here's the good and bad news. Good news first: Because so much of what IT does is more practice than process, we have firsthand experience with the sorts of tools that are useful for supporting practices -- tools like Visio, various IDEs, and project management software. The bad news: What we in internal IT know how to do is to build or integrate transactional systems -- the kind of systems that support business processes.
But building the sort of open-ended tools useful for supporting business practices? That's a practice, too. It just isn't one most IT shops have mastered. Has yours?
Aucun commentaire:
Enregistrer un commentaire