Enterprise

(LinuxWorld) -- Editor's note: The "I" in this story belongs to a systems consultant brought in to advise the executive committee on the choices they face with respect to Information Systems (IS) operations and an internally generated systems change proposal.

Martin Cutter Mills Inc. of St. Paul, Minnesota, its staff, structure, and plans, are fabrications but the situation presented, and the remedies offered, reflect the author's experience with real-world organizations facing broadly similar situations. Cutter Mills is imaginary, but the conditions, decisions, and outcomes described are broadly based on real events.

This story is primarily about governance. It's about what happens when senior management abdicates its responsibility for Information Systems (IS) to "technical people." Remember high school? The pretty party people acted as if nerds belonged to a lower social class and carried a contagious disease that lowered the social standing of those seen with them. When senior management acts like that with respect to IS, they put the company at risk and make attitudinal change a much bigger issue for an incoming CIO than anything directly related to systems or technology.

Setting the scene

Martin Cutter Mills employs about 1,800 people. It makes and packages milled grain products, predominantly breakfast foods, which it distributes under its own brands and the brands of other companies. Cutter's 5.5 percent market share makes it the fifth largest producer in a highly concentrated market in which the four biggest companies control 84 percent of North American production. Plant gate margins are good at about 65 percent, but stunning sales and administrative expenses leave the company with a paltry 2.7 percent return on sales of nearly $800 million in fiscal 2000.

Systems use at Cutter started in the 1970s with a warehouse management suite built on the IBM System 36. In the 1980s and early 1990s, Cutter added core manufacturing and order management capabilities using an AS/400. From about 1995 through to mid 1999, an IS team made substantial effort to rebuild this functionality in Windows, but production processing remained on the AS/400. In late 1999, an audit letter led to the decision to stop Windows development and seek a commercial package instead.

The project manager for the development effort organized the software selection and subsequent implementation. In that role, he reports directly to the IS steering committee and has now asked them to approve an "action plan." The committee brought me in to review his plan and make recommendations.

The project manager's plan

Four things in the plan stand out:

1. The plan is, by weight, roughly 80 percent about hardware with lots of loving detail about the SAN, network switches, and new rack servers. It contains little information about the software, transition plans, user needs to be met, or benefits to be obtained.
2. I am impressed by the quantity of calorie-free verbiage about "moving forward," business process re-engineering, and the need to "retain our competitive edge in a changing world." However, there's insignificant detail about actual change contemplated or where in the organization change will be focused.
3. The only place where a full list of the modules to be implemented can be found is in the label column for a Gantt chart masquerading as a project plan. Implementation times look surprisingly short and, subject to my somewhat sketchy knowledge of what specific module names translate to in terms of functionality for this vendor, the list doesn't look like it adds up to a complete enterprise system.
4. A few pages later, in the manpower and cost allocation table, some of the missing pieces turn up as interfacing projects. But that raises more questions because, according to a systems audit report from last year, the code Cutter is interfacing to is on the AS/400 they want to ship out. As a result, I suspect this plan is part of a backdoor attempt to complete the Windows-based software development effort killed after the May, 1999 audit review.

After a day or two of wandering around talking to employees, I learn:

1. Cutter Mills has always been hierarchical with promotion based more on going along with management views than on the ability to innovate successfully. This culture has taken a deeper hold on the older managers as generational conflicts sharpen. Specifically, in IS there's an entrenched "hear no evil, see no evil" policy among employees that reflects their fear of retribution should they be seen as stepping out of line with the opinions of the Finance VP -- to whom the IS department reports.
2. No one on the selection committee (or off, for that matter) was consulted on the plan. In a brilliant political maneuver, the project manager led committee members to believe that the plan had high-level support. They endorsed it publicly while opposing it privately.
3. The project manager did not consult with either customers or suppliers.
4. Since IS reports to Finance, the proposal is widely seen, and resented, as yet another attempt by the bean counters to impose more controls on the people who make the money. In reality, however, the Finance VP had no more directional influence than anyone else.

   In conversation, the Finance VP makes it clear, in fact, that he has no idea what changes are being proposed when he talks about current system response problems being resolved by the new gear. He expects that GL batch entries that now take 25-30 minutes to process will go in 1 or 2 minutes.

   The problem with this is that the new software doesn't support batches as he understands them. Changes are made in near-realtime as data is entered, controls are no longer based on balancing batch totals but on system internals and things like access permissions for operator groups. This stuff is not in the Finance VP's vocabulary. The new system, he's quite sure, will be a faster version of the old one with no implications for change in his operations.

5. Hierarchical communication is strictly enforced within IS.

   Even a simple help desk call is logged for approval if any kind of action is needed. Any substantial action goes up the corporate ladder to the steering committee for approval and then down to IS management. Interestingly, everything put forward by IS management gets approved by the steering committee.

6. IS staff are not allowed to speak directly to users regarding business issues and have to wear large, highly visible, name tags when they step outside the data center. Since no one else wears these, I can only assume that the tags are meant to mark IS people as untouchables.

I get no actual answers from either the project manager or the nominal Systems Director, but the sales and production people turn over their files and so I get the answers they got. From these, I learn:

1. The decision to go with Windows 2000 Server instead of the AS/400 was made purely on the software vendor's recommendation.
2. IBM, Oracle, and PeopleSoft were not shortlisted because their prices put them out of the ballpark
3. The project manager expects to make up for time lost "at the steering committee level" by bringing in people from a consulting firm whose tee-shirts some of his staff wear at work.

Each of these are true lies. This vendor doesn't offer an AS/400 product -- and may well have been picked for that reason. Other candidates seem to have offered very different product packages -- and may have been misled on what to propose. The steering committee delays were foreseeable -- and are probably being cited to offload the project manager's responsibility for the cost consequences of his earlier decisions.

You would expect the current plan to fit into a wider corporate IT vision, but it does not. There simply is no global plan or vision to be found. Instead, each new action is treated as a project undertaken for, and funded by, a divisional or other operational group. This creates a system that is locally satisfying but globally irresponsible. There are many examples of this syndrome's effects, but one, their existing supply chain solution, is particularly illustrative of the dismal consequences this produces.

A supply chain system links a company's ERP system with those maintained by its suppliers and so enables it to cost and schedule orders for which the required resources must be sourced from those suppliers.

Cutter has customers who have supply chain software and so insist that their suppliers, including Cutter, must accommodate it. Cutter, however, does not have a functioning ERP system for them to connect to. As a result, the first customer to make supply chain functionality a requirement for Cutter to continue doing business with them caused a major kerfuffle within Cutter's management and IT ranks.

The solution they arrived at perfectly illustrates IT management's abdication of their corporate responsibilities in favor of local solutions. Since this was seen as a marketing problem, they set up dedicated PCs in the marketing offices -- one for each customer requesting supply chain access. Each PC was the equipped with either a traditional telecom or network connection and the appropriate EDI software for that customer. These machines automatically issue acceptance confirmations on all volume and shipdate requests received and then print the orders.

When marketing gets the paper order, their people work the telephones to ensure that it is produced and shipped on time.

Marketing is quite proud of this solution because it has allowed them to present Cutter Mills as a flexible out-source supplier to various national brand marketing organizations. To Marketing, this looks like an efficient, low cost solution. The actual cost, however, is orders of magnitude greater than what they see being spent on a few PCs and daily telephone calls for production liaison. Those costs hardly amount to nickels and dimes; the thousand dollar bills are in manufacturing accommodations to cope with the resulting unpredictability in both product volume and product mix.

By simply accepting all such orders without back-checking availability-to-promise against production resources, the company forces itself to keep a larger finished goods inventory as a kind of surge protector and, more subtly, to make its raw products -- the ready-to-package stuff coming off the conveyor belts -- as interchangeable as possible.

The retail product name is on the boxes the stuff coming off the conveyor belt goes into. Since you can't store breakfast flakes in bulk (the edges crumble to produce a fine powder no one will buy) the answer is to put the same stuff into all the boxes so that production planning is unaffected by variations in the quantities boxed under each brand name produced. After all, as one sales guy expressed it to me, "corn flakes, is corn flakes."

Unfortunately, this isn't true and attempts to make it so are expensive. For example, the Winnipeg plant makes a multi-grain and raisin mix that's sold under various labels including a house brand for a Canadian chain of grocery superstores and that of a nationally advertised brand in the US. The American company, which presents the product as a premium brand, is mainly concerned about "mouthfeel" and requires all of its suppliers to meet various technical standards designed to ensure that the product meets consumer expectations.

During packaging, the product is placed in sealed plastic bags that are then put in pre-printed pressed paper boxes. For the Canadian superstores these are shipped directly to the stores and have an average shelf life there of about three days with most customers buying for weekly replenishment to produce an average box life in the 6- to 8-day range. The American brand, in contrast, is shipped to a variety of retailers including many smaller stores that extend the period between production and final consumption to 40 days or more.

As soon as the plastic bag is sealed in the packaging process water starts to migrate from the raisins (15.3 percent water initially) to some of the grain flakes (which average 3.9 percent water initially) and this, of course, affects crunchiness or "mouthfeel" -- thereby limiting shelf life. As a result, Cutter employs a variety of production and storage techniques --- including using additional humectants (which osmotically transfer water out of, and sugars into, grain flakes), allowing for longer pre-production drying times, and refrigerating finished product storage -- to slow this process enough to meet the US customer's standards.

Those actions raise fully allocated production costs by about 4 percent relative to the minimum needed to meet the Superstore's standards. Since the US product commands a premium this wouldn't be an issue except that the need to position Cutter as an instant response outsourcer forces the plant to make all of the product to the same standard. The lower-standard superstores get the same product as the persnickety Americans. Since superstore shipments account for about 75 percent of the demand for this product, the net result is an average 3 percent in unnecessary and uncompensated production cost.

Across the company, both the numbers and the accommodations made vary. In one area, product wastage is double what it should be, in another a customer responsible for about 30 percent of production requires that a relatively minor input be purchased from a company it owns at well above market prices. Storage cost for both raw and finished goods exceed industry averages for almost everything Cutter touches. "Turns" (the number of times inventory is replenished completely each year) are several points worse than industry averages too. Guessing the average cost of these adaptations at about 4 percent of revenue suggests that this marketing kludge is probably costing the company about $32 million a year. This amounts to a third more than the bottom-line.

Delivering bad news to people in denial

In the meeting called to discuss findings, they don't want to hear about governance or controls. Instead, they signal their eagerness not to face up to their responsibilities by talking about "where we are at this point in time" and about "moving forward from here." One even talks about "progressing the plan."

I was hired to provide a review of the current plan, not a new IT strategy. Two of the more aggressive vice presidents have talked to me before the meeting so I'm ready to look surprised -- and sketch out their more obvious options. I tell them we'll spend a few minutes looking at where they are and then talk about the options for the future.

Where Cutter finds itself today is easy:

1. The selected software is not a good fit for the business. It's built using an obsolete and unsustainable toolset, which means that even a successful implementation will require them to do it all over again in a few years. To make matters worse, the selected software vendor is probably headed for, if not business failure, almost certainly a kind of ghost-like existence in which customers get milked for support fees but nothing gets put back into product development.
2. Cutter has a history of slow and cancelled implementations for new software. The business relies on the stability of the core As/400 environment. Things work largely because people can trust those applications, and the data behind them, to be there. It is the stability of these core applications, however limited they are, that allows systems management to spend so much time and money working with things that are fundamentally unrelated to the business. This plan does not include contingencies for the continuation of those services past the machine's lease expiry. It relies, instead, on fast implementation of new Windows 2000-based software, including in-house developed stuff that this very committee canned in June, 1999.

The bottom line on this project is that pursuing it will place the company at serious risk of short-term operational failure.

As a group, they don't want to talk about reporting and control relationships and most assuredly don't want to know that the problems are natural and predictable responses to their organizational negligence. What they want is a set of action recommendations that get them off the hook. It's not that the committee didn't already know that this project needs to be cancelled, it's that the executives are deeply fractured along generational lines and they've all been trying to wield IS as a weapon against the other guy, Now, push has come to shove and they need some way to bail out of the mess they made.

Where to go from here

What's needed here, I tell them, is exactly what the plan promises but has no intention of delivering. Cutter needs an across-the-board IS re-engineering effort aimed at aligning systems operations with business needs. It takes time and effort to develop a real plan to do this. I certainly can't do it based on a few interviews focused on evaluating the existing project plan. What I can do, however, is talk about what the choices are and what to look for in evaluating them.

To re-engineer IS they must first decide what kind of systems culture they want. To discuss that issue in any meaningful way we have to compare two alternatives. Since, I tell them, their project manager has picked Windows and I'm a Unix bigot, those are the two cultures we'll compare, but they are not the only choices.

Staying with the AS/400 would provide a nice middle-of-the-road choice from a cost and security perspective. Many of the facilities, particularly the use of smart displays, network interoperability, and scalability within the limits of this business, are available in both environments. The big differences are in management approach and IS culture.

In the AS/400 world, control has to be hierarchical with the relationships between systems people and users mediated by one or more layers of resource managers who control what gets done, when it gets done, and who does it. As in Windows, the default decision in terms of adding or changing a service is "no." In the Unix world, control is distributed, users interact directly with systems staff, decisions to do work are mostly made by the people who do the work, and the default decision in terms of adding or changing a service is "yes".

This company has always been intensely hierarchical and the only things wrong with its present AS/400 set-up are that management is distracted, the software is hopelessly obsolete, the current machine is underpowered, and costs are out of control because the people in charge of IS starved the AS/400 operation while focusing on Windows. However, hire a good IS management team with the right experience and attitudes plus something like the J.D. Edwards OneWorld package to run on it, and Cutter can transform the existing systems organization into one that delivers first-class results while fitting well with the current corporate culture.

The other choice is to remake IS into something that drives corporate innovation by lowering costs and dispersing decision making to those most qualified to make them. I believe that this is a better long-run bet than extending the AS/400 investment. This choice gives Cutter a competitive advantage over its four biggest competitors -- one has OneWorld on a new iSeries, the second is in the late stages of being SAP'd, and the other two are said to have MVS-based data processing operations that I know nothing about.

One of the things they have to think about in this context, I tell them, is that you don't get competitive advantage or even competitive parity by adopting your competitor's software. You always end up at a relative disadvantage with this strategy because his people are ahead of yours on the learning and acceptance curve.

"So you're saying," one of them asks, "that we should not go with Edwards?" but I'm not saying that at all. With proper management, Edwards would be a lot better than what they have, or the stuff this project manager wants to buy or build. I tell them again that I'm not actually recommending a specific strategy. I'm pointing out differences so they can see what decisions have to be made and how those decisions fit together.

We'll start, I tell them, by specifying what Cutter needs to achieve and then look at how to get there using each of the two options. After that, we'll look at what each one means in terms of things like cost, productivity, and available software.

Agreeing to goals

Getting people to articulate systems goals is difficult because people tend not to look beyond work processes to the purposes of those processes. In talking about goals, people tend to talk about what they do, not why it's done. Here, people mentioned work processes like matching accounts receivable against orders, monitoring grain inventories at plant sites, and confirming the customer's payment record for order acceptance. All of these are important but none are relevant. The key to business process analysis, and so to strategic goal setting, is to focus on what has to be done, not on the processes implemented to do those things.

Finally, they grudgingly agree. A great systems solution would do two things:

1. Provide all the communications and record keeping needed to take an order from quotation through production to delivery.
2. Use the mix of incoming orders, both current and pending, to allocate work, across both time and production centers, to maximize returns on infrastructure.

A few people in the room think that this requires supply chain software -- but this is a serious mistake. The company functions as part of the supply chain for its bigger customers. These guys want automated ordering and immediate access to availability and delivered cost information. To bigger customers, this is immensely valuable because Cutter Mills is one of several intermediate producers from which they can source a range of products. The supply flexibility they get from this lets them maximize product turns while minimizing transaction costs and out-of-stock risk.

The right answer for Cutter is to adopt an integrated ERP/Financials system that lets Cutter participate fully in their customer's supply chains without racking up extra production or inventory expenses to do it. With an ERP system in place, a customer's order would become part of a production plan before being approved for acceptance. From Cutter's perspective, a fully functioning system that meshed with customer supply chain software would cut inventory costs, cut finished goods production costs, and improve revenue predictability.

The abstraction that makes this possible is the treatment of each order as a job-lot to be independently allocated among competing production facilities. This makes it possible to maximize use of the most efficient resources while minimizing overall idle time and avoiding wasteful production or inventory decisions. This would work for Cutter because its size, diversity, and customer relationships allow it to assume that there will always be orders in the pipeline and that these orders, although highly variable individually, will exhibit statistical stability.

This abstraction does not apply to the vast majority, whether measured by dollars or delivery criticality, of Cutter's suppliers. On the contrary, Cutter deals mainly with primary producers who incur high costs when faced with short-term change in the type, quantity, or quality of deliveries requested. Since these guys don't have the size and diversity needed for averaging effects across many orders to compensate for change in specific orders, any gains made by Cutter through use of automated supply chain software would come directly at their expense.

That would create a trading imbalance, inviting producers to counter with things like hedging and marketing co-operatives, thereby raising Cutter's input costs. Since these counter-measures have overheads paid to third parties, everybody concerned -- except the third parties -- would be worse off if Cutter tried to enforce use of automated supply chain logic.

The bottom line on this is that Cutter works at the end of the retailer's supply chain and should not try to add another link. ERP doesn't make sense at the producer level and so supply chain software to link to it doesn't make sense for Cutter. What Cutter needs is the classic, fully integrated ERP stuff and nothing more.

All of the major vendors, I tell them, including SAP, PeopleSoft, and Oracle offer exactly what they need in both Windows and Unix versions. These are rapid implementation packages in the $400,000 to $800,000 range for software and services that offer little up-front customization and deliver company-wide working systems quickly and cheaply.

At this point the Finance VP, who has been getting increasingly worried about my presentation, makes the strategic mistake that ties him so firmly to the existing IS group that he loses any chance of prevailing in next week's executive committee meeting. "We rejected bids from those guys," he says, with both anger and triumph obvious in his voice, "because they were priced way out of our league. Millions, not hundreds of thousands."

He hoped to discredit the entire exercise, but he had been setup by the project manager. What I suspect happened was that the project manager briefed the unwanted vendors on the importance of the customization work required to fit their products to the stuff he wants to carry forward from his own development effort. I don't know this for certain, since vendor complaints don't amount to evidence. However, the proposal he selected doesn't meet the detailed terms of reference set forth in the RFP, and there seems to be no available records on what was said at vendor briefings.

To answer the VP's charge, I point out that the customization requested in the RFP is not in the winning bid -- they were moved off-budget, and in-house. To support that I get them to compare several pages from the RFP to the modules and work listed in the plan. Heads nod. The Finance VP is isolated and knows it. I can see the Marketing and Production VPs are already planning the motion they'll be putting to the executive. Good, to the extent that I can take sides, I'm with them on this.

Once they agree that they need ERP with integrated financials and HR elements, we move to the discussion about getting that in place.

Governance issues top the list, and governance is a topic they don't want to discuss. Going through the CoBiT framework would, I'm sure, make them all extremely uncomfortable to the point of rebellion, but we have to discuss some high-level management issues whether they want to or not.

I hand out my Guide to Defenestration book and tell them that IS isn't any different from any other part of the organization. It has its internal incentives to growth and it has a job to do. The structure provided for it influences how the people hired to work in it behave in pursuit of those goals and it also influences how people outside IS see them. Right now, IS reports to Finance and one reason Cutter has had so much trouble implementing even simple new applications is that they're seen as part of Finance. IS is overhead and something to be worked around. IS is a necessary and resented imposition that gets in the way of getting the job done.

Out on a limb

I head out on a limb next. I say the new CIO must report to the CEO and the executive committee, and not because the person holding the Finance role can't handle the job, but because perception gets in the way of reality. Cutter needs production applications that production users accept enthusiastically. Having IS report to Finance creates an enormous, and unnecessary, implementation barrier that can be easily demolished, right now, before they try to hire a new CIO. Don't even bother, I tell them, to interview someone who doesn't make that a condition for considering the job.

As I expected, this gets a hostile, silent reaction. I move quickly to the most basic meat and potatoes issue: organizational posture. Do they want a rigidly controlled, hierarchical, organization that focuses on managing the resource? Alternatively, do they want a leadership-oriented organization that delegates decision making to the lowest level possible?

This decision is critical to the choice of technology. It is possible, I tell them, and to manage Unix in the traditional hierarchical way but the results will include user dissatisfaction and high cost, inefficient operation. That happens, I tell them, because Unix embeds very basic concepts about how systems work and provides for user freedom to do whatever they want to with the system. Using this technology in a tightly controlled way is unfortunately common but really means paying for many people whose job is to stomp out the use of the capabilities that come with the gear.

What Unix calls for is leadership, which is the process of getting more brains focused on a job that changes as you do it. This is opposed to management, which is the process of getting more hands on a well-defined job. Posture the systems organization as intensely hierarchical and you will get Windows like systems services whether you use Unix or not. You can, I tell them, drive a 2-inch nail with a sledgehammer if you want to -- but it doesn't work the other way. Try to apply a leadership-based approach in an all Windows environment and you'll find yourself doing the equivalent of trying to drive railway spikes with an 8-ounce hammer.

It's a difficult concept and acceptance isn't helped by the fact that most places they've seen Unix used have been disasters. This is usually because management tried to treat Unix as just another constrained resource to be managed. They don't understand, of course, but I ask them to read Chapter 3 of the Guide and a few promise to do it, so I let it go.

What it all costs

That brings us to infrastructure deployment options and costs. For this, we're going to compare the effect a Windows client-server approach with normal hierarchical systems management would have on the company to the effect of going with Unix, smart displays, and a leadership based approach to management.

Committee members know what PCs are and have some idea that the PC client-server architecture involves PC desktops and racks of PC servers, but they don't know what the Unix architecture is. I tell the committee there are three big differences:

• Instead of using PCs that use a 40-million-line OS to deliver applications running on Windows servers, the Unix architecture uses smart displays with 10,000-line operating systems to deliver applications that run on any server -- Windows, Unix, OS/400, MVS, or anything else. Smart displays, I tell them, are like dumb terminals, only with lots of built in smarts and brighter, clearer, graphics than most PCs. There are no moving parts, no user accessible software, and no noisy fans. Applications run on servers in one or more GUI type environments. You can, for example, run both Windows and Unix applications at the same time on the same screen and even cut and paste between them. Unlike PCs which have high failure rates and require frequent reboots and/or replacement, smart displays offer 300,000 hour mean-time-to-failure rates, usually last five to eight years, and don't change no matter what happens to the applications or servers.
• With Windows, networking and security are complicated issues. IS people work hard at keeping things running because your PC may have to use three or more networking technologies to talk to its local Windows server, an application in the data center, and something outside the local area network. By default, PCs have access to nothing, all access has to be granted and controlled. Users, for the same reason, may need to remember one password to get their PC to complete booting, another one to access an application, and yet more passwords and IDs to do something as simple as access the Internet.

  In Unix, all this goes away. You don't boot a smart display; you just turn it on and wait a few seconds for the login screen to come up. You login once, after that you only need to authenticate again if you access a restricted application or data set and stuff that's hard with Windows, like inter-office access, is trivially easy because the security, although tight, is fully automated and invisible to the user.

• The combination of high reliability with scalability means a Unix server grows with the business. Most places will have two machines for redundancy, but piling on more workload generally just means getting more bang for the buck. It's quite common, as a result, to see four or five major applications using completely different database backends running on the same server with a dozen minor applications.

  In contrast, the Windows approach requires that either one machine, or a whole cluster of machines, be devoted to each process. It might be possible to run several small applications on one machine, but few try it because the high failure rate makes it almost impossible to debug a system and, of course, a failure in one application shuts down people using other applications. It's quite common, consequently, to see Windows data centers supporting hundreds of rack-mounted servers.

With this background we start by looking at what the Windows decision would probably mean, including:

1. Eight Windows servers dedicated to the ERP system.

   These would be Compaq Proliants with four of the new 900-MHz Xeons and dual 505-gigabyte (net 244-gigabytes) external data stores on fiber channel controllers. The database servers would use clustering for both performance and reliability reasons with all gear at headquarters.

2. Approximately 560 PC clients.

   These would be Dell Optiplex 150s with Windows XP, 128-megabytes of RAM, and 17-inch screens. There's an odd, but common, reaction here. Dell, Windows XP, 17-inch, these are words they recognize. The committee members can't tell a Compaq Proliant from a compact car, but the Finance VP, in particular, warms appreciably at the sound of words he recognizes.

3. Current printing and networking technologies would be continued and all existing NT-based servers (42 of them) and applicable applications will be upgraded to Windows 2000.
4. The existing 520 or so PCs, all mid-range Compaqs unsuitable for XP, would be auctioned off or trashed.
5. IS staffing would increase from 32 to perhaps 40.

The Unix solution, in contrast, would have:

1. 120 NCD 21-inch smart displays for use by office staff.
2. 440 SunRay 17-inch smart displays for use by production and logistics staff.
3. Eight Sun Ultra 10 workstations with 21-inch screens for use in IS.
4. Two Sun V880 servers, each with 8 x 900-MHz CPUs, 32 gigabytes of RAM, and 800 gigabytes of internal disk to run the SunRays and all non ERP/Financial/HR applications.
5. Two Sun 4800 machines, each with 8 x 900-MHz CPUs, 16 gigabytes of disk, and directly connected 1.3 terabytes of T3 data stores to run all ERP and related applications.
6. The existing networks, local- and wide-area, along with all the Cisco, 3Com, and PC gear running it, would be entirely replaced with a flat, VPN-based, solution.
7. IS staff would give a series of introductory Linux courses including loading and using both Linux and OpenOffice.org as well as basic communications software for users whose PCs get replaced by smart displays. Users who participate would then be given the newly Linux-ed PCs for home use.

   As explained in an earlier article this step is tremendously important because it leads to creation of a pool of knowledgeable Unix users as a counterbalance to the centralizing tendency of the Unix/smart display architecture.

8. All existing non-PostScript printers would be gradually phased out and replaced by Minolta-QMS PostScript-compatible gear.
9. Total direct IS staffing would fall to about 22 people -- 18 in operations and four in the office of the CIO.

The biggest operational differences are in how people work with the systems, not the systems themselves. Both are based on centralized processing. With Windows, however, you also centralize control and responsibility, thus creating both opportunities and incentives for people to behave in counter-productive ways.

One of the issues here is depersonalization. We hear much about people not wanting to work with applications they don't perceive as theirs. It's true, this does have an enormous negative impact. Underlying it, however, is something more basic yet: by tying user perception of the application to a group, whether that's IS or Finance, you depersonalize it. That makes it easier for people to rationalize actions that sabotage acceptance.

In a well-run Unix environment, users work directly with IS staff to make real decisions. Not only does this give users an ownership stake in the application, but it also ties their perception of IS to particular individuals. When you personalize the relationship in this way, you make it harder for people to rationalize actions that sabotage acceptance.

With Unix, you centralize processing but try to decentralize control. This gives users what they otherwise try to take by stealth. The Cutter committee has a difficult time wrapping their collective brain around this because they think of the PC as distributed (the computer is on the user's desktop, right?) and Unix as centralized because the computer hums in the data center. In reality, this confuses presence with control. It is an objective of Unix administration to decentralize control.

You want to create knowledgeable users who control their relationships with IS. That's one reason I recommend that PCs replaced by smart displays be given to their former users as take-home Linux gear on the condition they attend a Linux or BSD course first. (The other reason is that having IT people give those introductory Unix courses strengthens both their relationships with users and their knowledge of Unix.)

A big part of Windows systems management, I tell them, is the exact opposite. You have to work hard at ensuring that you have control over those desktops and what people do with them. Otherwise, the whole network becomes utterly unmanageable. The result, of course, is that people will fight you for that control and so part of the company's energy is wasted in the conflict.

Cutter provides a perfect example. You think, I tell them, that you currently have 32 IT positions filled out of 35 FTEs approved. This, however, does not reflect your real staffing costs. Richard, who works for Finance in Accounts Payable, is really a full-time Windows support person and the only one there who can debug the completely audit-proof spreadsheets he wrote and got other people to use. Brenda, in HR, is another full-time Windows support person who has developed some reporting scripts for Microsoft Access that no one else understands or is allowed near. There's a quality control lab in every plant, and they all have IT people who don't report to IS. Telecom isn't handled by IS, and there are part-time people looking after that all over the company. All in, I'm guessing Cutter pays for upwards of 60 IT people -- almost all of who spend a big part of their time fighting each other.

Go all Windows and that situation gets worse. Cutter's AS/400 is a solid piece of gear. Replace it with applications that run on Windows servers and they can expect another half-dozen PC babysitters to emerge. It gets worse. People like Brenda will be unable to maintain the support level they provide now because they'll have a complicated PC client to deal with instead of the dumb but simple TN5250 emulation used now. That will inevitably mean that more people will stop doing their real jobs to provide stealth Windows support.

Go Unix and things get better. Richard and Brenda will have to leave or go back to their real jobs. There are no support requirements with smart displays -- none, zero, nada. The new software will obsolete the stuff they're so committed to, and, most importantly, the devolution of control to users will cut the ground out from under them.

Rough Comparisons: Unix vs. Windows at Cutter Mills CIO reports to CEO not CFO Systems mandate is corporate revenue growth, not cost savings in Finance Operational decisions made by those most concerned; not systems management Applications supported by highly motivated, knowledgeable, users; not Windows help desk people Applications always available -- 100% systems redundancy in place Server count drops from 42 now to 4 instead of rising to about 50 IS staffing falls from 35 to 22 instead of rising to about 40 Non-Capital IT cost plan for 2002 cut from 2.7 million to 1.8 million		Projected Costs with ERP
		With Windows	With Unix
Impact on Users	Average desktop application crashes per week1	120	0
	Average server failures per week2	4	0
	Performance (Load 1,000 e-mail messages)	>2 minutes	1-3 seconds
	Security (e.g. for employees authorized to access/change quality and health related records)	Login and Password within Advanced Directory; second login/password at client start-up	Smart Card plus login/Password at database level with full audit trail
	Security (from e-mail and related attacks)	Entirely reactive; every attack costs something	Entirely active; most attacks irrelevant
	Employee Support	Payroll based PC purchase program; remote access is by dial-in with PC-Anywhere	Older PCs given to those who take Linux training provided by IT staff; access is via dedicated VPN
Impact on Costs	Staffing Costs (fully burdened)3	$2,200,000	$1,430,000
	Approximate cost of ERP/Financials/HR software & uncustomized implementation	$600,000	$600,000
	Systems hardware and software costs	$1,380,0004	$1,821,0004
	Month 36 HW/SW replacement	$1,380,0005	$200,0005
	Total Five-Year Cost	$13,760,000	$9,171,000
1Failure rates for 560 PCs running 8 x 5 are based on the average time between failures (188 hours) for all Microsoft Windows-branded operating systems as computed from numbers reported by bugtoaster.com.   2Failure rates for 65 servers running 24 x 7 are based on the average time between failures (2983 hours) claimed by Microsoft for Windows 2000 Server. Bugtoaster appears to focus on desktops, the comparable number for Windows 2000 there is about 240 hours or about 45 failures per week.   3Unix salaries estimated at 65K fully burdened; Windows salaries at 55K.   4Cost information is from the Sun, Worldcom, Microsoft, Dell, Compaq, and Lucent Web sites as of Nov 18/01.   5Estimates are based on a single HW/SW refresh cycle for the Windows option. Actuals are likely to be higher. See the A strategic comparison of Windows vs. Unix earlier in this series for a discussion of this issue.

The big issue here, I tell them, pointing at the bottom lines in both columns, isn't this cost difference. The cost difference is important and typically increases as a percentage of total cost as the overall system increases in size. Again, cost is not the critical issue. Cutter doesn't make great returns, but a few million more or less on systems isn't going to make or break the company.

Embarking on a suicidal attempt to implement supply chain without considering the nature of your suppliers, and without having an ERP system in place can kill your company. The alternatives I've suggested look and sound as if they're technology based but they're not. They're based on first choosing how you want to posture systems in your company and then picking the technology to make that work.

Choose to position IS as an asset and you'll need Unix technology- and leadership-oriented control. Choose to position IS as an infrastructure item, something you treat as a cost of doing business, and you'll need traditional systems management and software like the Edwards OneWorld package on an iSeries. Don't make a decision and you'll get more of what you have -- uncontrolled cost growth, escalating failures, and the dominance of personal agendas over corporate responsibility.