[1] http://xent.ics.uci.edu/FoRK-archive/apr99/0686.html
------- Forwarded Message
Some afterthoughts as I am thinking about the meeting. One thing you did
ask about was, how does a company like GE do electronic commerce when they
are selling jet engines and components, etc. The answer is similar to
your WallMart comment and their proprietary information exchange. You
try to build the supply chain and share it with their customers. I am
assuming that the sales lead time for a jet engine is 2-3 years and also
highly dependent upon negotiations further down the supply chain. They should
build the supply chain and make sure it works with all potential customers--either
via proprietary standards or open Web and interoperability protocols. Whether
it's GE with jet engines or Dell with computers, they should do the integration
with their supply chain or enterprise resource planning software for their
customers.
One thing that will definitely change is that companies are loathe to announce
when upgrades will happen. Companies will never tell their customers when they
are going to 'upgrade' to the next version of a manufactured artifact because they
are afraid customers are going to wait. The only view a customer has into a company's
future release plans is through price discount understanding. While the value of
keeping this information proprietary keeps it out of the hands of their competitors,
it also keeps it out of the hands of their customers who place an extremely high
value on that information. For information artifacts, as in the Internet software
industry, the norm is vaporware--i.e. telling customers about software that they
plan on releasing (but may never get around to actually building) sometimes several
years in advance. This has competitive advantage in that if you say you are almost
finished building something that you haven't even started, then you scare off potential
competitors by diminishing the perceived opportunity.
Finally, when a company acquires another company, sometimes really large acquisitions
take years integrating their business processes. These processes are usually goal-oriented
and understood from the top down. There is no explicit model. At the execution level,
I think we agree, the choice of a company's ERP system could greatly effect how quickly
the transaction cost of the merger. Incompatible ERP systems could take many times longer
than integrating business processes, because software is more precise than human-effected
processes and needs to be specified at a much greater level of detail. You can always
change the way people do things, but with software, there's always a risk that two
large and complex systems will always be inherently incompatible.
Also, I am very biased with respect to technology; I believe
that businesses that depend on others should integrate their
business processes before they even think about acquisition.
Obviously I think the best way to integrate cross-corporate processes
is with a lightweight, end-user understandable, dynamic, mobile, and decentralized
process modeling, deployment, and execution environment (any come to mind ;-)
This is why there are strategic alliances and corporate investment,
both pre-steps to acquisition.
Also, Rohit came running into my office the minute after you left
with the articles he was trying to find. Both of us couldn't find
it because 'baseball' is only mentioned in the header of the message.
He ended up finding it by doing a mail search of all 200Meg on
his laptop and his Mac popped up a 'found' right when his battery
gave out in the meeting.
Anyways, here's the link. http://xent.ics.uci.edu/FoRK-archive/apr99/0686.html
Probably a few words on FoRK. FoRK stands for friends of
Rohit Khare, loosely defined. It's an intimidating email list that
runs about 20% extreme technical mulling and speculation and 80% just
general BS'ing. All the key technical WWW players as well as the
key technical decision makers at all the Internet companies are
either subscribed or read the archives including several key
technologists, executives, and others. It's a public archive with
severe group penalties for asking questions that could otherwise be
answered with a search engine. The single biggest benefit to me
is that it's impossible to keep up with all the tech news, particulary
Web and standards efforts.
Further, even reading the tech news, you don't really understand how its going
to effect all the other players, etc. Collectively, we are all more highly informed
than each of us would be able to be individually. FoRK's main benefit is that
it's interpersonal and highly interactive. Other information sources, like
Tasty Bits (http://www.tbtf.com/) or Strategic News Service (SNS http://www.tapsns.com/)
are more top down and centrally controlled, even though they have some readership feedback.
Interactivity and personal understanding is the key. FoRK allows you to
make certain assumptions about the readership without having to go through
the song and dance of negotiating a shared understanding so that you can
get to the point that you think is interesting. From the FAQ:
Don't just send us raw bits, because we are
all well read. Send a paragraph or two about the bits. To quote
the brilliant Dan Connolly,
The paragraph or two of personal analysis is the essential
part. Without that, a "hey, read this!" message is nothing
more than a commercial. In this age of information
overload, let's do each other the favor of information
_reduction_.
One thing I've learned over the years about big businesses, is that they
are upgrade wary of software. This is somewhat because MSFT charges a large
pop for every set of bug fixes they put out, but more importantly, you can't
found an enterprise on shifting infrastructure. John King's thesis is that
you don't see the benefits of infrastructure until it stops changing. Sun
Microsystems when they were putting a version of Java out a week finally
had to go to a fixed and planned release schedule (although they haven't
completely yet) saying at a given time, what version will be out when.
One of the most useful things would be for a customer to say, I am thinking
of building this Web-based java software, starting in June 2000. What version
(pre-release, alpha, beta, stable, platforms, etc.) should we use if we
will do the development on platform X and will probably take 12 months to
release our product. The worst thing that can happen to a large software project
is to have to upgrade the technologies in the middle of development and hope
nothing breaks. If you had some way to predict that, for software or other
industries, then that'd be tremendously useful. Some companies put high
level technology roadmaps on their Web pages, but mostly that information is
difficult to find and not up to date for external consumption. You almost
need a registrar, clearinghouse, or an independent organization or company
to provide those services to the corporate world at large.
This is kind of related to Rohits' agents example, where the owners of
the information don't want outsiders to know exactly what their technology
roadmap is, but they want to provide them the ability to discover the
appropriate properties about it that are useful to them. Proprietary
information needs to be split in some way such that a consumer can
break it down according to their criteria, and the producer doesn't always
know what that is. For instance, Motorola trying to break into the
Azerbaijan, Kazakhstan and Uzbekistan markets. They had an anthropologist
figure out that a key purchasing criteria for those markets was being
American manufactured. http://www.ics.uci.edu/~ebradner/USAToday
------- End Forwarded Message