Managing the Corporate Intranet

Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

In most companies that were early web adopters, it has been with the tolerance of management, rather than at their urging, that the Intranet was formed. Lucky is the manager who understands what's going on.

Executives are getting little help with this from their IS staffs. Some corporate IS departments are still mired in the mainframe world and are only starting to explore client-server. Those that are heavily committed to client-server have jumped into some very expensive proprietary technologies and big-bang projects that require a lot of administration and maintenance, and it will be some time before they get their heads unstuck enough to see what is happening around them.

When they do, they may find that their original assumptions about client-server technology have to be completely rethought. "IS people were asleep when personal computers happened," says Chris Koehncke of Nortel, "and I think they are asleep now on the World Wide Web."

In companies where employees are truly empowered, people tend to take Intranet technology and run with it in all kinds of unexpected ways. In fact, you might gauge the intellectual health and level of entrepreneurship within your own organization by the speed at which web systems are adopted and grow.

In companies where employees are functionally empowered, technologically enabled and intellectually challenged, web technology may spread very fast. In companies that ration technology and where initiative is stifled by layers of bureaucratic control, you may see some signs of life on the web front, but the general rate of adoption may be incredibly slow. The quickest adoption often occurs at companies where savvy managers catch on and help lead the charge.

Intranets work best when people are given the same freedom to use them that they now have with ordinary business applications like desktop publishing and spreadsheets. It's important to recognize that web technology-at its core-is not rocket science. It's just another business communications medium, like desktop publishing is now, but one in which the network substitutes for paper. But it's also important to realize that web will exponentially increase the speed and immediacy of business communications and that it will eventually suck in all the other information stream-not just words and pictures, but data, multimedia, messaging, conferencing, and applications.

When this happens, watch for a further flattening of organizational structures and drastic changes in the management of information systems. In the Web Era, mid-level managers will have an even smaller role as the intermediaries who interpret and transfer information between the bottom and top rungs of the corporate ladder. Grunt-level workers and executives will have a common platform for communication where they can silently (or even audibly) audit each others' web pages, hear each others' concerns, and add their voices to corporate-wide discussion groups focused on special topics. The new technology will enhance the communication of corporate goals, performance targets, and employee feedback across the organizational nexus.

IS managers may find their entire world shifting around them once again, as the internal web becomes the dominant environment for delivering data and applications. The entire method of application design and delivery may require a new phase of reengineering with a focus on more modular, applet- based information systems, and a more serious look at ways of integrating the entire information stream, including data, documents, multimedia, and applications.

IS will certainly continue to be the guardian of back-end legacy data, but will find more and more of their information being served out directly onto the Intranet. Many application programming functions may devolve out to individual departments or information centers, as people create their own form-based interfaces to data sources.

None of this should suggest that an internal web is unmanageable, or that there aren't concrete steps that should be taken to manage it. In fact, there are many management issues that must and should be addressed to ensure that people can use the new technologies in efficient and productive ways. This chapter will discuss the key management concepts, and suggest ways that management can cope with the coming web explosion.

The Matter of Control

Large organizations love control, and the larger the organization, the more effort they spend controlling things. It's no wonder, then, that one of the biggest impediments to adoption of a web may be the control issue.

People make no bones about it. "Our company likes control," one client told me. "We might not want just anyone going out and setting up a web server, or using one of these things."

But think about it. If the company likes controls so much, where are the controls on the telephone and e-mail systems? Who controls the desktop publishing and interoffice mail systems? Anyone can use a word processing program to prepare a document, print as many copies as they want and drop all those copies into interoffice mail to be distributed throughout the company with no questions asked! Where's the control there?

"We can't control the use of word processors or the copying machine," people may argue. "That would be impossible. Everybody needs those tools to do their job."

My point exactly! You don't mind employees wasting money to print all this paper and hand-deliver it to locations worldwide. They can do that without restriction. But if someone wants to use the network to bypass these archaic information distribution systems, they have to ask for permission first. Does that really make sense?

The control issue is a vestigial part of the old information systems models. In traditional computing environments, you start with the idea that everything is prohibited unless someone in power enables it. Thus, people who want access to computer resources are typically given access only if they request it.

With web systems, on the other hand, access is automatically granted unless it is specifically denied. In other words, everyone starts with full access to the system, and they are restricted from key applications only where that type of control is absolutely necessary (such as with highly confidential product designs, personnel records-that sort of thing). The new paradigm is that you let the system grow free at the grass roots, then you take a little time to manicure the lawn.

Understanding the Web Control Model

That's not to say that control is not a legitimate issue. There must always be some amount of access control, even in an open system like a web. It's just that the control model has changed; almost inverted. On its face, a web server is the epitome of control. With web, however, the controls are non-intrusive, built-in, and decentralized.

Can anyone access just any information on a web server? No... People who are looking at my web site are seeing only the information the author or webmaster wants them to see. In other words, the individual author or provider of information exercises control over who sees what by moving it into the web server document folders. No one (unless they are a somewhat bored and very talented hacker) can see any other information on the server platform unless it is physically moved into the server folders.

In a web system, therefore, there are two levels of control involved, that can be called author versus viewer control, or server-side control versus client-side control.

Think of the web server as sort of neutral territory being visited from both sides by two opposing camps. On one side are the authors of the information, who are mainly responsible for publishing it and keeping it up-to-date. On the other side are the users of the information, who are mainly responsible for browsing through it, learning from it, and occasionally interacting with it. Here's how the control systems work on both sides of the equation:

Author/Server Control

On the author/server side, we have the issue of who will be able to create new information and deposit it inside the web server directories, who will be able to update the information, and who will be able to tamper with the configuration of the file systems or other aspects of the server host computer. In this case, the server may be controlled by the people who contribute the information to it, which may be an individual, a workgroup, a department, or a division.

In these situations, the traditional control models are more likely to apply: The web server could be installed with server directories mounted as a local file system on each contributor's machine. That way, each author could directly access and edit the information just as though it were stored on a local hard drive.

In this case, permissions would be set on the server side to make sure that only members of the group could access the directories to change their content. Or an automated process could be used to transfer and convert web content in a shared workgroup directory to a set of production server directories controlled by a webmaster.

Workgroup server model.

On a wide area network with built-in Internet software, access to the server directories could be provided in other ways: including FTP and telnet either through the network or through dial-up SLIP or PPP connections. Thus, for example, authors might create and manage the content on their own local computers, then use FTP to transfer the completed files over to the web server. A time-triggered "cron" job could be set up as an batch process to automatically do this on a regular schedule.

Viewer/Client Control

Access control issues are entirely different on the viewer or client side of the web model. Here we start with the idea that there is no control at all, other than the fact that the access is read-only. In other words, anyone on the network can hit the web site and extract the contents, but no one can edit or change the contents at the site. That's for starters.

Beginning with this open model of universal read-only user access, we then have other levels of access control:

Read-write access to selected materials. The authors or developers of the web site can selectively provide users with both read access and write access to certain materials. For instance, the authors might include interactive forms that can insert or update records in a database at the author's site. Though rarer, its not hard to imagine that future server-side applications will be used to pass edited documents back and forth from authors on the server side to collaborators on the client side. IP address filtering. The authors or developers of a web site can selectively allow or deny access from specified IP addresses. Most likely, this would be used to limit access to certain audiences, such as people in the same department or work group, or to certain classes of users such as dealers or sales reps. User authentication. If desired, web authors and developers can take their sites all the way back to the old login model where everyone who accesses the site must have a user ID and password. Naturally, this increases the administrative burden considerably, since each user ID and password must be set up individually at the web server.

Though access issues may seem a somewhat arcane subject, they are really at the core of the entire management issue. Though the web comes with certain access controls built in by default (read-write on author/server side, read-only on user/client side), much of the creative work in developing web systems revolves around how access is manipulated to provide different kinds of services and functionality.

The 80-20 Rule

One of the key moments in computing history was probably the day-sometime back in the 1970s or early 1980s-when they changed the name of most corporate computer departments from "data processing" (or DP) to "information systems" (or IS). This change recognized that computers could be used to deliver something more than just raw data in the form of mind-deadening numbers; instead they could be used to provide people with useful information.

The job of computer departments, then, was to capture information, process it, and present it to users in an automated way. And they've done an admirable job, considering what they've had to work with. Back in the days of data processing, the computer room was like a scene out of Dr. Frankenstein's lab. The old CRT displays were covered with gibberish. Today your very own "personal" computer is more likely to greet you with a smile, a catchy tune, or even visions of flying toasters romping in outer space.

But the job of automating information systems is far from complete. Even today, with all their growth and technical sophistication, corporate information systems only handle about 20 percent of the total information available in the enterprise. The other 80 percent falls under the category of miscellaneous. Information systems are great at handling all the mission-critical data, including customer information and accounting records, but not all the other stuff, such as reports, memos, catalogs, specifications, manuals, budgets, project schedules-you name it.

Nowadays, these various bits of information are prepared on computers, of course. But then they often get transferred straight into the old information system: the copier, mail room, and filing cabinet systems that handle tons of paper every day. Normally, you can't see these documents online unless you're the one who authored them. Or if they are online, they're online in an inaccessible way: in certain people's in-boxes, on certain network file servers that can only be accessed by certain groups at certain times, locked in PC WinHelp systems, and so forth. There hasn't been a way to take all of this information and catalog it the same way you can catalog information in a database. Raw information is a messy business that doesn't easily submit to neat solutions the way raw data does.

The problem of automating the other 80 percent of corporate information, therefore, has been partly due to a lack of suitable technology. That's no longer true with the web. First, people put their information online using web publishing tools, conferencing tools, and messaging tools-instead of going onto paper with the old desktop publishing tools. Then a search engine comes behind and makes it all accessible enterprise-wide within seconds.

The feat you accomplish is a little like what might have happened if you had deliberately set out to bring online the other 80 percent of data that remains untouched by the corporate IS function. But instead of years of dogged efforts by squadrons of bleary-eyed IS people and contract programmers, it all happens automatically within seconds.

Of course, the fact that it happens magically on search engines like Lycos doesn't mean it will happen magically on your Intranet. It won't happen until the web is fully populated with information from all segments of your organization. So the trick will be how to get the ball rolling, how to gain wide acceptance of web technology in your organization, and how to be "smart" in your use of the technology so that everyone remains productive during the transition.

The Role of the Vanguard Team

Probably the best way to manage an Intranet may be to have an internal vanguard team that functions as consultants and advisors to the rest of the organization on web technology. It may be that your company already has such a group that has charged ahead with its own internal web site and that is full of people who already salivate over the technology. If not, it's likely that such a team might be assembled from the ranks of IS, network services, or other groups that have an IT orientation. Or you may want to pick individuals from various disciplines, such as technical communications, marketing communications, database services, corporate communications, and IS.

The responsibilities of an internal vanguard team could be quite diverse, but would probably include:

  • Promoting the use of web technology within the organization

  • Helping train employees in how to use the technology

  • Developing standards and templates for web page design to promote a more consistent interface and level of quality

  • Developing standards and templates for offline tools that feed content into the web

  • Researching and recommending productivity tools that will help automate web publishing and programming functions

  • Dealing with software licensing and distribution for various common web tools, such as browser and servers

  • Evaluating and critiquing the contribution of different departments to the overall Web

  • Answering questions and providing support functions such as a 24-hour help center or online discussion groups where people can get their questions answered

  • Advising departments on innovative ways to apply web technology to specific applications

  • Providing the technical expertise where needed to develop more advanced applications such as interactive forms, CGI programs, and database integration

  • Keeping track of changes in the Web, possibly by certifying Web sites or providing a registration form

  • Creating and maintaining high-level menus or search tools that provide a centralized path for accessing all Web resources

  • Assisting in managing the overall Web, including broken link analysis and usage reporting.

    An internal consulting group set up to perform these tasks can help promote organization goals without creating a centralized bureaucracy. At first it may be that such a group exists independently of IS, since in many cases an Intranet is considered a foreign concern to IS. It may be that someday this evolves into a department that actually swallows the IS function completely.

    The Importance of Standards

    Another area where management can make a difference in the development of an Intranet is by promoting standards for development, design, and production of the new systems. There are basically two ways your company can deal with an internal web: (1) Everybody reinvent the wheel everyday and do things in the hardest possible way, or (2) everybody benefit from a set of standards, guidelines and tools that will help people work smart and be as productive as possible. Admittedly, these are two opposite extremes of the spectrum. There are gray areas in the middle, somewhere. But it pays to examine both the worst case and the best case to make a point.

    Let's look at the worst case first. Assume that everyone is on their own without any standards, guidelines, or training to help them. First, everyone will have to go off and learn about web technology on their own. They'll have to read books like this one (actually, not a bad idea) or do about a year's worth of thinking and study on the subject before they realize how web-based communications can benefit the entire organization. Then they'll have to find it in their heart to put the organization's best interests ahead of their own lethargy, and start using the web. Not too likely, right?

    Now let's look at how a well-designed set of standards, templates, guidelines, tools, and workflows can help an organization. The workflow is built around a set of templates and the way that information is deposited into them and then makes its way from the author's desk to the web.

    The templates would contain a set of style tags (also called a style sheet) that everyone should use to format their documents: Heading 1 for major headings, Heading 2 for subheadings, Bullet for bullets, Body for body text, and so on. To use the style tags, just point at the paragraph you're typing and select the correct tag from the style menu. It's a little disorienting the first few times, but you get used to it. You can distribute the templates as hyperlinked directly from a web page, and include online instructions on how to use them or a full-fledged online style guide.

    Workgroup model using standard templates.

    It's easier to distribute the workload in such a way that everyone cooperates in maintaining a publishing standard. This helps us avoid the retraining that would be involved in a move to new tools, or the rework and doubling of effort required if we have to reformat everything that everyone writes. Style sheets are not hard to use: in fact, they will make everyone more productive even if you aren't doing web publishing.

    For each set of templates, there will be a set of map files and a tool like HTML Transit, WebMaker, or Cyberleaf that can suck the documents right out of their source directories and turn them into published web documents on the fly. The important thing is that the templates and the map files be designed to work together by someone who understands style sheets, HTML conversions, the tools involved, and the formatting requirements of the web.

    Once all the elements in a template-based workflow are set up and meshed properly, the conversion process is so easy that a single administrative assistant (or webmaster) could easily handle all the conversions required by a workgroup-or even a set of workgroups-without seriously breaking stride.

    Styles sheets are destined to become an important part of the corporate Intranet, as future browsers and Internet tools begin incorporating the style sheet standards developed as part of the HTML 3.2 specification (see http://w3.org/). Microsoft Internet Explorer 3.0 was the first browser to recognize these new cascading style sheets, and Netscape 4.0 (Communicator) also came online with its own style sheet features. If you want to enforce look-and-feel standards enterprise-wide, there may be no better way to do it.

    Achieving Buy-In from Employees and Management

    Letting people take the technology and run with it is one thing. But if you're going to create a truly company-wide Intranet, you're going to need participation from everyone. That means not only identifying mission-critical applications and creating teams to develop them, but getting everyone to use the Intranet as a standard conduit for their own critical information.

    One of your greatest challenges in doing this will be helping people understand the benefits of the new communications model. Just because you find this technology powerful and productive, you shouldn't assume everyone will share your feelings automatically. To get everyone working on the same channel, it's going to be necessary to achieve buy-in from both the executive level and the grunt level. To bring benefits to the entire enterprise, the web must achieve a certain level of saturation within the organization.

    Preliminary reports back from the front say that it's not easy to impress rank-and-file employees in the benefits of this technology unless several things happen:

    Upper management makes it clear that it supports the effort, and that it considers company-wide Intranet to be an important strategic tool of the organization. The web contains a critical mass of important applications that people need in their daily work and that are essential time-savers. That means not just documents but crucial up-to-the-minute data, like the profit-and-loss statements Chevron maintains for each team (see Chapter 4). Rank-and-file employees get the tools and training they need to make web publishing easy-and even fun.

    Never underestimate the enthusiasm of empowered employees. In places where employees have been given the right tools, the right models, the right emphasis on benefits, and the right training the Intranet has achieved critical mass and taken off. In some places, the Intranet is so popular that other problems arise: the problems of keeping people from doing too much with it and using it for inappropriate purposes, such as putting up pictures of their children and dogs.

    In places where employees don't get the proper tools and training, where management imprimatur is absent, or where the web is still in an experimental or stripped-down stage, the task will be harder. People may applaud the new technologies, then turn around and go right back to doing things the old way.

    There's also something be said for a laissez-faire attitude. After all, you shouldn't have to force people to use web publishing tools, any more than you have to force them to use desktop publishing. People already use desktop publishing as a matter of convenience, to help rapidly develop the standard written communications required in every job. They should use web publishing the same way, but also for its added benefit of allowing document distribution without the hassle of printing and distributing paper documents. When people see the benefits of the Intranet fairly presented-that it can speed up their communications and take the drudgery out of distribution-it should be sufficient incentive for them to get involved.

  • Submit a Comment

    Loading Comments...