Business Validation
of E-Business
Applications at
Hewlett-Packard
by André Kuper, Bublu Thakur-Weigold,
Tom Brown, and Ilse Schultz
A challenge that Hewlett-Packard (HP) shares with other manufacturers is
how to link disparate platforms and processes across the increasingly
complex networks that deliver solutions to customers. New technology and
the associated processes can actually amplify this challenge by imposing
constraints on the flexibility of the system infrastructure. The increased
complexity and accelerated pace of change
that HP and its business partners are facing
require a pragmatic approach to implementing new technology and processes.
Using two pilot projects as examples, we
will explore how we pilot, define, and
measure performance in a real business
situation to exploit the opportunities that
technology offers us. This will provide
insight into how a veteran of change has
successfully achieved nimble, value-driven
implementation. The focus is on how applications and their testing add value to our
competitive positioning. This includes all the
changes that are needed in employee
behavior to make the transformation of our
business processes a success. An obvious
difference is that our program managers are
speaking a different language than the
technology providers. They don’t talk technology. They talk business.
Alignment on what constitutes success is
critical for evaluating the outcome of application testing — corporate politics must be
removed from the decisionmaking equation. Choosing to move on (to another platform and process) is only possible with
measurable objectives in place and a
shared common view of the business
context. Determining the impact on the
business and people is a critical element of
this process. It helps us to avoid the pitfall of
new processes and applications that unintentionally extend the life of legacy systems.
Furthermore, our business environment
requires us to accommodate ongoing
change. Therefore, technology- or processinduced constraints need to be part of the
evaluation. The same business reality
requires us to move fast — we cannot afford
to deal with past problems.
Overreliance on technology as “the solution” is a symptom of our current business
environment. As cellular phone pioneer
Martin Cooper observes, “Everyone is
talking about technology, when what’s
important is what people do with technology.” Cooper is even more adamant
about what everyone has wrong right now:
It’s the concept of universal solutions. In other words, people think
you can come up with one universal
gadget or system or solution that
solves a whole bunch of problems.
That if you find the Holy Grail of
solutions then everyone will flock to
you. Everyone is wrong. People are
different. They have different
needs.… The suggestion that all of
us should be served by one solution
is just insane [1].
Cooper’s comments underscore the need
for technology roadmaps for operations and
business management to be aligned and
tested in the environment in which they are
going to be used. Previews of the future are
Vol. 14, No. 9 September 2001
11
speculative at best, whereas existing investment and resource constraints set boundary
conditions for strategic and operational
direction. It is all about people and the way
people work. HP has a history of learning by
doing, testing several aspects simultaneously, to allow fast and precise direction
changes.
They can provide an
excuse for continuing poor
processes or adopting
technology that does not
fit the need.
OUR APPROACH TO IMPLEMENTING NEW
TECHNOLOGIES AND PROCESSES
To get to more realistic expectations for
technology and applications in particular,
we must appreciate the businesses environments that use them. Therefore, starting
with the business needs is crucial. These
challenges provide the framework for technology selection based on a representative
pilot that measures performance in the
environment in which the application will
be used. Following is an action-oriented
framework that helps us do just that.
Define the burning platform. “What is the
compelling reason for change?” is the
fundamental question that needs to be
answered before making any meaningful
change in processes and application environments. We need to face the reality that
forces us to change the way we work,
because doing nothing, continuing the way
we work now, is not a realistic option.
Create alignment. Now that we have
established a business reason for change,
we need to ensure that everyone understands why he or she needs to get involved.
The change will impact everyone’s behavior. Moreover, early involvement of all stakeholders prevents mistakes and delays later
in the process.
Identify performance gaps. With the
context for our project or initiative in place,
we need to understand and measure our
current performance in light of how we
12
September 2001 Vol. 14, No. 9
should perform. This performance gap
provides guidance for measurable objectives. Performance is a result of people’s
behavior, and our organizational structure
and incentives drive this behavior.
Unearth assumptions. One of the critical
success factors is making our assumptions
visible. These assumptions — when not
known and therefore not validated or
disproven — are a major barrier to success.
They can provide an excuse for continuing
poor processes or adopting technology that
does not fit the need. A perfect example is
the assumption that if people do not do
what is required, they need to be educated.
Behavior is primarily a result of structure
and metrics, not necessarily of knowledge
and skills. Therefore, the assumptions of
both management and employees need to
be known and clarified.
Discover existing knowledge. Intellectual
capital, especially tacit knowledge about
processes and dynamics of the supply
chain, is a critical competitive advantage.
Displacing this knowledge by forcing a new
process not only does a disservice to the
employees involved, it also destroys an
opportunity for positive involvement of your
stakeholders. We start with what people
know to reduce our implementation time
and to eliminate sources for disconnect or
missed opportunities.
Define metrics. The burning platform,
performance gaps, assumptions, and
existing knowledge form the basis for
setting measurable objectives. They way we
measure our project or initiative’s performance must provide a balanced scorecard.
That is, it needs to provide measures that
allow us to make tradeoffs. For example,
cycle time needs to be balanced with yield,
and inventory needs to be balanced with
our performance in the eyes of the
customer.
©2001 Cutter Information Corp.
Qualify pilot. Selecting where we are going
to test and measure new technology is as
important as why and what we are going to
validate. Issues we need to consider include
how well the results can be generalized,
complexity that can create leverage in the
future, the readiness of all involved to act,
and sponsorship.
Define processes. Specifying what
processes are affected and which processes
are going to be used is extremely important.
This is the real value of any application
implementation, and it is where competitive
differentiators are maintained. Furthermore,
it provides a safeguard against politically
motivated decisions.
Change people’s behavior. A major pitfall
is getting people excited about a new way
of doing things and then failing to deliver.
What is important is whether people actually positively change their behavior. If they
revert to the old ways, the new process has
failed to overcome the most fundamental
objective. This requirement includes how
people’s performance is evaluated, how the
structure of the organization enables and
supports them to change, and ongoing
dialogue. Change does not happen in a
vacuum; it requires careful and elaborate
management. This aspect of application
implementation [and the preparation] will
consume more than 80% of the time and
resources.
Test under realistic conditions. Many
applications make assumptions about how
the users will interact with the system. We
find two characteristics to be critical: ease
of use and scalability. Often applications fail
to address the workflow of their users or
make implicit process assumptions that
create negative user experiences. Often
vendors (and, unfortunately, business
managers) believe training solves problems
caused by poor usability and application
complexity. For their part, users are very
creative in finding new ways of using applications that do not match the developers’
intentions. This frequently results in application loads that were not anticipated.
Unexpected application loading can be a
major inhibitor of scalability. For example,
system access problems can result from
higher-than-expected server requests when
users adopt secondary functionality as the
engine for their critical processes. Similarily,
programmers often underestimate the
complexity of business processes and
impose limitations that actually negate
potential gains. Immersing vendors or IT
professionals in the business environment
during testing is a proven strategy. For the
pilot manager, it adds another benefit: he or
she is not the intermediary for user gripes
and vendor justification.
Immersing vendors or
IT professionals in the
business environment
during testing is a
proven strategy.
Expand use. Making choices is what a
correctly positioned and executed initiative
is all about. Rolling out an application is not
about bolting on new modules, adding new
business units, or increasing the number of
partners, it is about evolving processes and
making tradeoffs in the course of action.
As there is no one-size-fits-all solution,
appreciation for the diversity in processes
and behaviors needs to drive technology
adoption.
Move on. If a technology or application
does not meet our business objectives, we
need to replace it and move on. Best of
breed or best of class are meaningless in
our business environment, which undergoes
rapid and relentless change. Does an application accomplish what we intended? Did
we unearth technology limitations that
unduly burden our employees? Are the
process modifications limiting our flexibility?
Is the return on investment high enough?
This pragmatic approach to technology is
urgently needed. In our desire to keep up
Get the Cutter Edge free: www.cutter.com/consortium/
Vol. 14, No. 9 September 2001
13
with the latest technology, we forget that
being hip doesn’t guarantee business
success — as the current business climate
illustrates. However, this healthy skepticism
of technology for its own sake should not
be allowed to prevent change when the
business situation truly calls for a different
approach.
CASES IN POINT
Anytime changes occur,
they need to be
documented and tested
according to a rigorous
requirements process in
order to meet customer
expectations.
To illustrate our approach to implementing
new technology and processes, we selected
two pilots in which we transformed our
existing processes to incorporate the
Internet. Both e-business applications
changed fundamentally in the process of
implementation. We collaborated with the
technology providers to transfer test results
to application improvements. Moreover, we
worked together to ensure that testing positioned HP’s unique process knowledge as
complementary to the applications. The
latter allows us to develop joint going-tomarket strategies with unique value to our
customers.
Implementing an Internet-Enabled
Information Backbone
The Burning Platform
The telecommunications market is going
through tremendous change in the way its
infrastructure is set up and used. Users are
looking for faster access and more comprehensive services. Telecom service providers
are increasingly using third parties to
provide the global data and voice network
infrastructure. Finally, network equipment
providers are in the midst of establishing
standards in an environment of rapidly
emerging technologies and shakeout. The
business objectives are disparate: telecoms
are looking for robust, long-lasting, and standardized infrastructure and debt load reduction; network deployment companies are
14
September 2001 Vol. 14, No. 9
looking for flexibility to meet future revenue
opportunities; and equipment providers are
trying to own the emerging standards and
secure their future viability.
Hewlett-Packard is delivering into this
complex demand-side network. Lack of
visibility of the global demand increases the
business risk and requires more inventory
to meet short delivery time expectations.
Similarly, the global nature of e-business
systems with different network requirements stresses the supply-side network.
Technology discontinuity and long lead
times provide additional challenges.
Anytime changes occur, they need to be
documented and tested according to a
rigorous requirements process in order to
meet customer expectations. To cope with
technology churn, [lifetime buys] are the
order of the day.
All these forces create downward pressure
on margins and profitability and increase
the task load of the program managers. This
task load reduces the number of programs
they can work on and hence the revenue
opportunities for HP. To meet and exceed
growth and profitability objectives, HP’s
Telecom Infrastructure Division (TID)
needed to change its processes and collaborate with its up- and downstream partners.
Visibility of the bidirectional information,
material, and finance flows was a key
requirement in achieving these goals. An
upcoming platform change provided additional urgency.
Discover Existing Knowledge
TID started with exploring the existing
processes, identifying owners, decisionmakers, transfer points (handoffs) of flows,
inputs, outputs, and established practices.
This allowed the quick creation and
implementation of a representation of the
supply chain flows. In the process, TID
©2001 Cutter Information Corp.
immediately started to improve on them.
The flow representation allowed members
of the team to design the supply chain for
the new platform with an understanding of
the current dynamics. While expanding the
view to the upstream and downstream partners, they discovered existing processes,
behaviors, and systems that allowed an
end-to-end supply chain view with little
investment. This visibility drove collaboration. By sharing knowledge and having an
Internet-based platform to do so, they
started to build trust with their partners.
Collaborative Processes
The partnership involved not only internal
and external supply chain partners, but also
the application service provider, Global
Factory. Visibility, we discovered, is a
powerful driver for change. As we changed
our expectations, relationships changed
with them. We found that there’s no substitute for learning by doing when you’re
implementing and testing an application.
For example, we jointly worked on the
layout of the user desktop when we found
the sequence of user actions, the labels on
buttons, and the interpretation of the data
were hampered by their presentation to the
users. We also discovered the quirks of
Internet accessibility though different corporate networks; for example, we registered
as a child-friendly site in order to penetrate
the barriers companies had built to protect
themselves against liability for Web-surfing
employees.
We started with the forecasting process, and
it soon became clear that there were ways
this process could be improved. The net
result was a collaborative forecasting
process that requires less time than the
original internally focused approach.
Similarly, the existing documentation in the
two manufacturing locations allowed for
tracking and tracing parts, yield, and quality
issues, but now as a collaborative. This
again eliminated significant amounts of time
previously spent hunting down information,
and TID became a better partner because
of it.
One of the major test insights was to accelerate data pulls from resident and legacy
systems by exploiting their export capabilities. The ubiquitous desktop spreadsheet as
formatter for data pulls eliminated IT
involvement and shifted the information
management power to the operations
people. Rather than adding IT as an intermediary for translating information needs to
system data pulls, we collaboratively identified default exported spreadsheet data
elements to be transferred into the information backbone. This increases our flexibility
to connect disparate systems and mitigates
the risk of system lifecycles that are out of
sync with our application’s lifecycle.
We found that there’s no
substitute for learning by
doing when you’re
implementing and testing
an application.
Define Performance
The cost of labor in terms of the task load
and ability to manage additional programs
has a profound impact on learning curves
and usability. On-the-job assimilation and
the time needed to involve partners provide
a benchmark for future rollouts and cost to
the company, as well as providing guidance
to our partner on support requirements.
Firstly, it is very important to establish
acceptable levels before the implementation and testing occur. Secondly, as not all of
these costs will be transparent to our
accounting systems, tracking and documenting actual performance are critical.
As the information backbone to support a
new platform became a reality, we started
to eye the current platform. The downturn
had a profound effect on our customer
demand and the end-to-end supply chain
flows. Being able to meet a 24-hour delivery
window with lower costs of goods sold
Get the Cutter Edge free: www.cutter.com/consortium/
Vol. 14, No. 9 September 2001
15
Without this testing,
expansion of tool use
would likely have
generated user
dissatisfaction and cost
overruns by both partners.
(COGS) gained urgency. We started to
define performance in terms of the profit
and loss of the system. Risk and reward
sharing of all partners involved became an
integral part of our view on the world. As we
were preparing to roll out, we achieved a
time-to-market reduction of two months, a
collaborative forecasting process that
reduced labor by four hours a week, and a
process to track and trace flows. These
improvements were achieved in just six
weeks with very little investment.
relying on only one option, spot markets,
does not make business sense, as all electric power users in California can confirm.
KeyChain, HP’s private exchange for supplyside collaboration, is a good example of a
successful pilot of new technology. Although
initially conceived as a proof of concept,
KeyChain quickly became a driver for
business transformation. Not only did this
happen with high velocity, it also provided
focus on how technology adoption itself
should be collaborative.
Test Under Realistic Conditions
The drive for improved asset management
has shifted our business environment
from internally integrated supply chains
to managing complex networks with
contract manufacturers, third-party logistics
providers, suppliers, and other highly
specialized service providers. Managing
these networks requires more than transactions. Some critical business needs on the
supply side are purchase order collaboration, forecast collaboration, and event or
exception management. These processes
tend to be time-consuming and often result
in delays. These delays increase costs:
they add the need to buffer for uncertainty
through increased inventory, create
surprises that require overtime and [“nonrecurrent engineering,”] induce stock outs, or
drive rework. Most of all, they shift the focus
to reactive management of the supply
network. HP’s Operations Procurement saw
an opportunity to reduce these delays and
reduce costs through a private exchange.
In the process of populating the information
backbone, we discovered the need for
sampling and archiving information for
further analysis. Our initial assumption
of real-time visibility as a guide for action
underestimated the accessibility to end-toend ERP and MRP information by operations professionals. Furthermore, having a
single workspace for all their activities
excited them. This drove some database
architecture innovations that were outside
the scope of the original pilot but greatly
increased the value to the users. Similarly,
users were up- and downloading multiple
large files, uncovering file management
needs for the tool and network bandwidth
limitations within the company. Without this
testing, expansion of tool use would likely
have generated user dissatisfaction and cost
overruns by both partners. Furthermore,
user perceptions and behavior are powerful
agents in enhancing real business benefits.
Piloting a Private Exchange: KeyChain
Face Reality
As many of Hewlett-Packard’s procurement
processes address complex information,
material, and financial flows in partnership
with suppliers, public environments have
limited impact on our business. Furthermore, from a risk management perspective,
16
September 2001 Vol. 14, No. 9
Translate Vision to Value
The first step was a proof of concept.
KeyChain commenced as a start-up within
HP with seed money and set deliverables.
Apart from testing and validating the technology and process assumptions, KeyChain
needed a business sponsor to apply and test
its concept. That is, it needed to create
alignment on action in the context of a crit©2001 Cutter Information Corp.
ical business need, a “burning platform.”
The start-up’s first business sponsor was
manufacturing operations in Puerto Rico.
Government incentives facilitated this
match. The sponsorship and funding were
key enablers for success and provided the
direction for action (hence velocity, not just
speed). The value perceived by the business
was in exception management and contract
negotiation. Although the business unit was
looking to automate standard processes that
added little value, enabling event-driven
collaborative purchase order management
with alerts was of most value.
This was different from the transaction
management the start-up thought to be its
core competency. In the process of working
with its sponsor, KeyChain moved from
discrete order process management to
supply-side collaboration. Similarly, the
change in business model drove this
emerging business from exploring a technology opportunity to having customers
involved in its growth. This involvement
translated into measurable objectives:
improved responsiveness measured in
reduced cycle time, reduced error rate
measured in reduced task load, and visibility measured in time spent on the relationships. Moreover, the impact on COGS
ensured the linkage between strategic and
operational objectives.
Build Strategies
Now that a first customer was involved,
further expansion needed to be considered.
A major pitfall for all organizations deploying
new technologies is the heavy, and sometimes debilitating, impact powerful first
customers can have on the structuring and
deployment of technology and processes.
By extending the sponsorship and involvement to the supply chain council that
represents our operations management
interests and the executive council that
represents our strategic interests, this risk
was mitigated. As these groups also provide
funding, they are in a position to guide
KeyChain through emerging business challenges and opportunities. Furthermore, they
provide a platform for sharing evolving intellectual capital. They help determine which
suppliers, contract manufacturers, thirdparty logistics providers, and parts or
subassemblies to focus on. This approach
provided a competitive differentiator that
sets KeyChain apart from its competitors,
who also started with a transaction focus
but evolved much more slowly to include
the value-added services our business units
were looking for.
Interestingly, the involvement of these
different decisionmakers also clarified the
flexibility e-business applications can offer.1
By describing the role of public2 and private
exchanges in detail, managers have clear
choices in mitigating business risk.
Testing this application in a business environment unearthed more than technology
and process. It challenged assumptions
about business strategy and customer value.
Working with keychain’s business partners,
first Puerto Rico Operations then the supply
chain council, proved to be a great enabler
for functionality, use, and specifying the test
environment. It also invited Operations
Procurement and KeyChain to rethink their
relations within the supply chain network.
That transformation provided guidance for
further testing and rollout in HP.
Learn by Doing
Focusing on processes and people is critical
to driving application characteristics like
platform robustness, program infrastructure,
deployment, and support. The process and
relationships provide the competitive
advantage enabled by the application. They
also allow us to be pragmatic: if a partner is
Get the Cutter Edge free: www.cutter.com/consortium/
1
See, for example, “Supply Chain
Strategy: Real Options for Doing
Business at Internet Speed,”
in Achieving Supply Chain
Excellence Through Technology II.
Montgomery Research, 1999.
2
One example is Converge, a
result of a similar pilot,
TradingHubs, discussed in André
Kuper, “Implementing E-Business
Strategy to Create Flexibility and
Velocity,” Cutter IT Journal, Vol.
14, No. 5 (May 2001), pp. 5-11.
Vol. 14, No. 9 September 2001
17
André Kuper works with internal
and external experts to define
business models incorporating the
power of the Internet. He creates
supply chain communities,
balancing the need for personal
contact, access to information,
and action. Mr. Kuper collaborates
with a multitude of partners to
define business webs driven by
customer needs for small business, consumer, and major
account segments. He focuses on
velocity, volatility, and flexibility.
Mr. Kuper holds master’s degrees
in applied physics and instructional design from The University
of Twente (UT), The Netherlands.
Bublu Thakur-Weigold has
worked with the logistics modules
of SAP software for over 10 years,
the first 5 of which she spent at
Andersen Consulting. Since joining
Hewlett-Packard Consulting in
1995, she has performed in
various project roles, ranging from
design and implementation to
process analysis and modeling,
project management, and the
management of change.
Ms. Thakur-Weigold holds a bachelor of science degree in management science from M.I.T., with a
specialty in operations research.
already part of another marketplace, we
enable linkage. This allows us to test the
application in a heterogeneous environment
and provides a benchmark with a similar
application. However, we cannot be everything to everyone. Therefore, when merging
disparate architectures, the business objectives and experience (unique intellectual
capital) provide reference. If an application
fails to support processes that were developed to meet unique business needs or
requires unique code modifications, we
need to select another application.
Finally, we change the way people are
working. If an application is not used
because it fails to meet critical user needs,
it has no business impact and needs to
be discarded in favor of an alternative.
Similarly, if an application facilitates business as usual, the return on investment will
be absent. For example, one of our partners
used documents to drive its business
processes. Moving to a Web-based environment was a profound change. This provided
a stringent litmus test for the application
capabilities; would this company adopt the
new processes and use the Internet? This
may sound mundane, but it illustrates how
seemingly simple aspects of how people
manage their business can enable change
or be a major barrier to performance
improvement.
Test Under Realistic Conditions
Testing in defined relationships where
alignment is a prerequisite for operational
excellence made a difference. KeyChain
achieved a 50% cycle time reduction for its
sponsor. This had a major impact on
contract negotiations and business continuity. The number of errors was significantly
reduced by moving from manual to automated processes. This proves the need for
testing an application where it will be used
and by whom it will be used. KeyChain
18
September 2001 Vol. 14, No. 9
testing increased the value contributed by
the buyers and procurement coordinators,
the real users. Their role shifted from crisis
management and tedious processes to relationship management, while reducing their
task load by 30% and 40%, respectively.
Their adoption of KeyChain and its process
automation provided the business case for
rollout.
Allowing partners to manage inventory and
to connect to our IT backbone required
more than a technology fix — it changed
the way people worked. These realistic
conditions and the business value remove
politics from the decision to continue or
move on. For example, purchase order
collaboration differs from the existing
procurement process. Does KeyChain add
complexity or value? Similarly, aggregation,
complexity, and replenishment planning
start to change people’s jobs. Does
KeyChain facilitate this change or is it a
barrier? The test of intangible value
centered on process changes and integration by choice. KeyChain passed, and these
benefits eventually will reduce COGS.
Influence Performance
Building a private exchange environment
from scratch created the opportunity to
change the way we work with our supplyside partners. Rationalizing our purchase
order processes and creating a collaborative
framework were very different from plugging and playing an e-business application.
The technology functioned as an enabler for
business change in Hewlett-Packard and its
supplying partners. By making the technology subservient to the business goals
and involving different layers of our enterprise in the implementation and testing
process, we exploited the opportunity to
incorporate the Internet in a portfolio of
applications to manage the supply risk to
our enterprise.
©2001 Cutter Information Corp.
CONCLUSION
To implement e-business applications is to
transform a business. It requires a strategy,
a common understanding of why it makes
business sense, and a robust process to
make decisions. These decisions are tradeoffs. They need to balance business needs
and application capabilities. Testing applications requires testing functionality under
real business conditions with business
results as the measure. Moreover, implementing e-business applications is about
changing people’s behavior and providing
an organizational and incentive structure to
make this behavioral change a success. If
the application fails to contribute to the way
people work or perpetuates existing poor
practices, we should move on.
The applications we discussed in this article
are driven by business needs; however they
differ in focus, velocity, and flexibility. They
also differ in IT involvement in the testing.
KeyChain is about procurement leverage
and mitigating our supply risk. It involves
significant capital investment and resource
consumption. Furthermore, KeyChain
demonstrates successful enterprise leverage
of an internal investment. It provides
common processes where they make
sense, significantly reducing cost and
increasing procurement value. Testing
involved the roles and responsibilities of
procurement specialists and buyers and
required operations IT resources.
e-service provider had to facilitate testing in
its hosting environment and the users’ work
environment. Exploiting existing systems
and processes was key to allowing change.
In both cases, disparate processes and
systems were integrated and tested. In both
cases, collaborative processes were an
outcome. These successful examples illustrate how we at Hewlett-Packard constantly
transform ourselves and adopt new technology by testing in a real business environment with a compelling reason for change
beyond the application functionality.
Applications are an enabler — not the
change agents — for maintaining a viable
business environment in an increasingly
complex world.
REFERENCE
1. “Everyone Is Wrong: Q&A with Martin
Cooper.” Technology Review (June 2001),
pp. 83-86.
Tom Brown is a program manager
in the Telecommunications
Infrastructure Division’s Project
Center. The Project Center is
responsible for the development
and adaptation of HP and thirdparty technologies for use as
repeatable solutions in the telecommunications market space.
Mr. Brown is responsible for the
GSM Base Station Controller
program, supporting 2G and 2G+,
with investigations into UMTS/3G
under way. The Base Station
Controller provides the infrastructure for the computing and
communications elements of the
GSM solution, with the customer
providing the application. Mr.
Brown has been with HP for 6
years and previously worked
for a large network equipment
provider for 21 years.
Ilse Schultz is the KeyChain
program manager at HewlettPackard (HP). KeyChain is an
HP private Internet marketplace
that focuses on creating supply
chain collaboration solutions for
HP and its partners. Ms. Schultz
has 13 years of experience in
supply chain management and
IT management in the high-tech
industry.
The information backbone is about visibility
in a complex, volatile environment, where
decisionmaking requires knowledge and
collaboration to succeed. This pilot
occurred in a business unit with little
money, few resources, and unique requirements. Testing occurred with program
managers, forecasting specialists, planners,
and operations experts. No local IT
resources were required, and the
Get the Cutter Edge free: www.cutter.com/consortium/
Vol. 14, No. 9 September 2001
19