- log in
Posted by Marc Cecere on June 24, 2009
by Marc Cecere
Process based IT organizations have become the rage. These are IT shops that group people around the processes they support, such as software distribution or requirements definition, or by business processes such as claims management. In contrast, traditional shops group people by technologies (e.g. mainframe, desktop), internal customers (e.g. wealth management, retail banking), or geographies (e.g. France, Asia).
There are two types of process based organizations – IT and business. IT process organizations typically follow ITIL for infrastructure and a software lifecycle for applications. Using ITIL, they form groups around process associated with problem management, storage, or configuration management. For applications groups, they may have people dedicated to requirements development, coding or testing. Business process based IT shops are less prevalent but may include IT associated with claims processing in an insurance company or collections in a credit card company.
IT shops today are aggressively moving towards process based organizations, particularly within infrastructure. Furthermore, several trendy models - including Demand/Supply, Plan/Build/Run, and component based - typically include process groups as their underlying structure. When Forrester reviewed 10 future IT models proposed by major consulting firms, 8 were clearly IT process based. .
The catch – most shops aren’t ready, or don’t have a strong enough need to move to a process based structure. In trying to do so, they may find that:
• They lack the skills. Their people think in terms of specific technologies, applications, or customers.
• Their installed base of systems is too complex. Multiple versions of applications, operating systems, middleware, and hardware greatly increase the challenge of creating processes to cross these environments.
• They lack the necessary tools. Development, infrastructure, and other tools are often targeted to a specific environment.
• Current frameworks are not sufficient. COBIT, for example, is occasionally used by applications groups, but is not sufficiently prescriptive or adequately supported by tools.
• Their size limits the potential benefits. Consolidation and cost reduction are two benefits from moving to a process model. However, small shops can realize these benefits without changing their models.
• Process models will disrupt existing client relationships. Changing apps groups from organizing around customers to organizing around processes can reduce local knowledge and increase bureaucracy in getting apps work done.
Overcoming these challenges requires some changes. Buddy Long, former VP of Global Data Center Services for Disney, stated you need 4 things before moving to a process organization:
1. Simplicity. Numerous operating systems, hardware platforms, and vendors create a barrier to processes that cross these environments. For example, software distribution across multiple versions of mainframes, departmental servers, and desktop machines is very difficult for a single group to implement and maintain.
2. Heavy investment in tools. In order to, for example, diagnose problems across multiple operating systems and hardware platforms, you need sophisticated tools that can accommodate this diversity.
3. Processes that scale. Requirements development may need to scale across multiple development environments, geographies, groups of different sizes. In large fragmented organizations, apps groups typically have multiple versions of these processes.
4. People who think in terms of processes. Most IT people progress through their careers by solving problems for customers or with specific systems. Particularly at the lower levels of the organization, their knowledge is much stronger in how a particular system works than processes that cross multiple systems.
IT shops will become increasingly process oriented in structure, and for many good reasons. These newer models can overcome traditional silos, better align with how work is done and reduce costs. However, moving too quickly with a highly complex installed base and people who think in terms of technology will cause more problems than it solves.
Search Forrester's Blogs
Save Money On Your Next Software Negotiation
Work with our software negotiation experts to save 10–20% on your next contract »
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »
- Alex Cullen (5)
- Andrew Bartels (76)
- Ashutosh Sharma (1)
- Bobby Cameron (4)
- Brian Hopkins (1)
- Chris Mines (36)
- Claire Schooley (39)
- Clement Teo (3)
- Craig Le Clair (4)
- Dan Bieler (105)
- Dane Anderson (12)
- Doug Washburn (1)
- Frank Gillett (36)
- Frank Liu (1)
- Fred Giron (11)
- George Lawrie (1)
- Holger Kisker (1)
- Jennifer Adams (3)
- Jennifer Belissent, Ph.D. (131)
- John Brand (12)
- John McCarthy (19)
- JP Gownder (1)
- Kyle McNabb (3)
- Marc Cecere (10)
- Martha Bennett (2)
- Michael Barnes (2)
- Michael Yamnitsky (13)
- Mike Gualtieri (1)
- Nate Fleming (1)
- Nigel Fenwick (114)
- Pascal Matzke (1)
- Paul Miller (10)
- Philipp Karcher (17)
- Sharyn Leaver (38)
- Skip Snow (8)
- Steven Peltzman (2)
- Ted Schadler (131)
- Tim Sheedy (32)
- TJ Keitt (45)
- Tyler McDaniel (1)