Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Organizational Issues
All the finest processes in the world won't help if the organization is not structured to support any technology, so the IT group must structure for success. Success in this case consists in supporting the legacy and client/server environments while technologies and people integrate.
How do we get there? We start by looking at the balance of people, process and technology in mathematical terms:
Technical change + resources and time for implementation = learning + economic benefits to the firm + benefits to the worker.
The balance among technology, resources, and time—and the benefits that the combination of these ingredients can generate—will result in a successful transformation.
NOTE
Realize that all information technologies you purchase are important and must be managed in a consistent manner (with enterprise-wide application development standards). Second, realize that your staff, no matter what technology platform they work on, must be treated the same. I know that this is sometimes difficult. We all have biases, but the only way to unify an IT organization is to treat everyone equally.
Global Infrastructures
Thinking globally and working locally (as it is often stated) is not a simple act when you're standardizing on IT tools and processes. For example, using an authority hierarchy for signature approval of completed work can cause great difficulty from one culture to another.
Nothing should change. The people issues and processes should be flexible enough to adapt to regional locations as well as corporate headquarters. (The key word is adapt—not build something new.) If not, the consequences are obvious. Costs will continue to skyrocket and RAS (reliability, availability, and serviceability) will continue to deteriorate.
Decentralized Staff
In many companies, IT staff resides at their customer sites, and in many cases report right into their business units. The intent is that they will work closely with the customer, respond in a timely manner based on the customer's specific needs, and therefore develop a more acceptable or polished finished product. This is a very positive way to build quality IT systems and cultivate customer relations.
The downside is that many IT professionals who are assigned to customer sites or report into the divisions wander from the central policies and procedures of the central IT organization. Although everyone says it's better to standardize for the good of the company, that's just corporate lip service; no one wants to cooperate. Decentralized IT staffs do things their way for the good of their customers only. How do you overcome this tendency? Using a set of governance policies allows the decentralized staff to play a role in the development of the enterprise's IT standards. Having a voice makes a big difference, and getting input from the decentralized staff creates a more robust set of standards.
In conjunction with the governance policies between the centralized and the decentralized IT staff, there's also a process, which I refer to as production acceptance. This is the process that builds the bridge. Just like San Francisco's Golden Gate Bridge, which is continuously being painted, the production acceptance process promotes ongoing communication between centralized and decentralized organizations. It actually forces people to adhere to a minimum set of standards and guidelines and work together daily. For additional information on production acceptance, see IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures (Prentice Hall, 2002, ISBN 0-13-087678-X).
Roles and Responsibilities
Defining everyone's roles and responsibilities is essential in a network environment. Demarcation between organizations is a blur at best.
Single Job Descriptions for Similar Technologies
One of the simplest and most unused approaches to unifying the IT organization during the merger of the legacy and client/server staffs is job classification. Most organizations continue to divide their staffs using job descriptions that are germane to the legacy or client/server environments. For example, client/server developers are sometimes classified as microsystems analysts, as opposed to their counterparts on the mainframe, who are called systems analysts.
I recommend that you use the same titles and diversify the skill sets of both groups. This allows the team to emerge naturally and helps everyone feel that they are first-class citizens.
Each position group should also share a similar pay range. This promotes cross-training and stops the exodus from one technical area to another when hot technologies drive the cost of technical talent through the roof. It establishes clarity for the organization structure, and skills—rather than the differences or perceived differences in job titles—become the issue of discussion.
Responsibilities by Application
Thanks to network computing, support requirements need to be defined for each production application deployed on your network. Part of the production acceptance process is to clearly define who does what to whom and when. Each application has different requirements and needs special attention.
Staffing
Staffing should be based on the organizational structure and the new IT model of doing more with less. To be effective, we must provide equal or better levels of service at lower cost. To accomplish this daunting task, I recommend implementing the processes and systems management model, and then automate, automate, automate! The best way to control costs and provide effective service is to standardize, invest in tools, and provide the right staffing to meet the new service model.
Key areas of focus are systems administration, networking, database administration, and production control. Production control is probably one of the most important areas. In the past, companies tended to staff the other functions but leave out production control (particularly in organizations without mainframe experience).
NOTE
As discussed in previous articles for IT, I like to define production as any system, network, application, or database that requires RAS (reliability, availability, and serviceability). Once you define your scope of production in the new model, there must be a group accountable for delivery and ownership of the production environment. I call it production control.
Processes and Procedures
I have depicted the appropriate set of processes and procedures in my Systems Management Implementation model (see Figure 1). Continuing the operations support role, I recommend implementation of the processes and procedures that support high reliability, availability, serviceability, and manageability in the new network enterprise. Each function is broken into groups according to the service level it provides. The production acceptance (PA) process is at the top of the pyramid because it's the umbrella for establishing communication and management of the entire infrastructure.
){kind=link}
Figure 1 The Systems Management Implementation model.
Once the planning is complete and the process and procedures are defined, it becomes necessary to begin implementation of the tools, standards, and support infrastructure for the network-computing environment. Another important component in network computing is automating the environment through systems management tools. You must first define the process and then automate with software tools. Why define the processes first? Because the tools are only as good as the processes behind them, you must automate. To support your enterprise and be active, you must automate the environment.
Looking Beyond Technology
Technology can do ill as easily as good. The only way you can take full advantage of technology is by resolving people and process issues. I'm not saying to slow down or stop implementing new goodies. On the contrary, things will never slow down! Just give the two P's (people and processes) a chance.