OK, I'll admit that my message was a bit of a troll, however, one of my
previous supervisors did an ERP consolidation within the DOD and it was
successful. There weren't dozens of ERP instances but, there were
several from 2 vendors and he used a similar strategy. To paraphrase
him, he examined the value he was getting from the maintenance fees and
figured he had been taxed long enough without seeing any measureable
benefits. He wanted either a refund or services. From his viewpoint, the
ERP system was the integration strategy. I've heard a number of CIOs say
the same thing.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Steve Jones
Sent: Tuesday, April 03, 2007 2:20 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Kaufman on Reuse
& SOA
Ahhh the vision of "one ERP" there is another angle here which
is "if it ain't broke don't fix it". The cost of doing an ERP
rationalisation strategy can be measured in the hundreds of millions,
its a nice idea that SAP or Oracle would do the rationalisation for free
but until I see a case study where that happened I'm not going to
believe that it is possible. Shifting to a global vanilla (or standard
configured) instance is a major programme of work, both in terms of
operations and in terms of training and "buy-in", treating it as a pure
technology exercise is a sure way to have some fairly major problems
down the road (and ERP is littered with massive numbers of high cost
failures).
So surely the SOA approach is "if it works for you then fine, we
need to wrap it and expose it in a standardised way so it plays nicely
in the enterprise playground" that way it is up to the business whether,
and when, rationalisation happens and the rationalisation can be
"hidden" from the rest of the business via business services and their
ultimate technical implementation. Big bang ERP upgrade is on its way
out, the future is incremental upgrade, and its the business service
view that will enable that to happen.
Steve
On 02 Apr 2007 09:07:13 -0700, Bill Barr <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
The solution is remote integration that integrates 50
disparate ERPs in each distributor site. ESB is best
way to go as of today.
No, there's a much easier way. Discover which of those
50 share the same vendor and if there are 2 or more, call up each vendor
and have them come do the integration/consolidation of their own
systems, free of charge. Then, pit the vendors against each other for
the best and lowest-cost migration path to one ERP system; the
efficiency and effectiveness of their first-round consolidation will
weigh heavily when selecting the final, sole ERP vendor. Astute vendor
management is a better solution than technology.
--
email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
________________________________
From:
[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Jerry
Zhu
Sent: Monday, April 02, 2007 8:42 AM
To:
[email protected]
<mailto:[email protected]>
Subject: Re: [service-orientated-architecture]
Kaufman on Reuse & SOA
Shared infrastructure... interesting.
What about a manufacturer having 50 plants all
over
the world distributing their products to large
retailers such as Home Depot and Lowe's and 60
independent distributors. There are 50 ERPs. One
business goal is to have distributors directly
participating inventory management to achive
real time
order fufilment across the world.
The solution is remote integration that
integrates 50
disparate EPRs in each distributor site. ESB is
best
way to go as of today.
How your shared infrastructure concept fit into
this
scenario? Factor out from 50 ERP systems and
construct one ERP infrastructure hosted in the
Corp
headquater?
I think that there are three requirements to
have a
shared infrastruture: shared business process,
Separation of business logic from data logic,
and
separation of content from presentation.
Jerry
--- Todd Biske < [EMAIL PROTECTED]
<mailto:todd.biske%40gmail.com> > wrote:
> This is a pretty good article, however, they
miss
> out on one
> important factor: Marketing. I still refer
back to
> a presentation I
> heard at SD East way back in 1998.
Unfortunately, I
> don't recall the
> speaker, but he had established reuse programs
at a
> variety of
> enterprises, some successful and some not
> successful. He indicated
> that the factor that influenced success the
most was
> marketing. If
> the groups that had reusable
> components/services/whatever were able
> to do an effective job in marketing their
goods and
> getting the word
> out, the reuse program as a whole would be
more
> successful.
>
> This article focuses in on governance, which
is
> clearly an important
> aspect, but focusing in on governance alone
still
> means those service
> owners are sitting back and waiting for
customers to
> show up. While
> the architectural governance committee will
> hopefully catch a good
> number of potential customers and send them in
the
> direction of the
> service owner, that committee should be
striving to
> reach "rubber
> stamp" status, meaning the project teams
should have
> already sought
> out potential services for reuse. This means
that
> the service owners
> need to be marketing their services
effectively so
> that they get
> found in the first place. I imagine the
potential
> customer using
> Google searches on the service catalog, but
then
> within the service
> catalog, you'd have a very Amazon-like feel
that may
> say things like
> "30% of other customers found this service
> interesting..." Service
> owners would be monitoring this data to
understand
> why consumers are
> or are not using their services.
Interestingly,
> this is exactly what
> companies like Flashline and ComponentSource
were
> trying to do back
> in the 2000 timeframe, with Flashline having a
> product to establish
> your own internal "marketplace" while
> ComponentSource was much more
> of a hosted solution intended at a community
broader
> than the
> enterprise. With the potential to utilize
hosted
> services always on
> the rise, this makes it even more interesting,
> because you may want
> your service catalog to show you both
internally
> created solutions,
> as well as potential hosted solutions. Think
of it
> as amazon.com on
> the inside + with amazon partner content
integrated
> from the outside.
>
> This is a great conceptual model, however, I
don't
> know what the
> potential of this would be today. How many
> enterprises have a
> service library large enough to warrant
establishing
> this rich of a
> marketplace-like infrastructure? If you go
beyond
> service reuse,
> however, and include shared libraries, and
even
> shared
> infrastructure, now the inventory may be large
> enough to warrant an
> investment.
>
> Now time to copy and paste this into a blog
entry.
> -tb
>
> On Mar 30, 2007, at 4:06 AM, Gervas Douglas
wrote:
>
> > <<Improving the reusability of business
process
> and technology assets
> > helps businesses get to market faster,
reduce
> costs and achieve more
> > consistent results. This important concept
has
> recently been receiving
> > attention because Service Oriented
Architectures
> (SOA) are enabling
> > businesses to achieve much more frequent and
> extensive reuse of
> > business services, software and data.
> >
> > One of the main drivers for the adoption of
SOA is
> the business need
> > to be more flexible and responsive to
change.
> Change is part of the
> > business ecosystem. A long time business
partner
> can suddenly become a
> > fierce competitor as the result of a merger.
The
> dynamic between
> > partners, suppliers and customers is in
constant
> flux. A business
> > loses the ability to adapt if its software
and
> supporting IT
> > infrastructure is inflexible. And to become
more
> flexible, a
> > comprehensive strategy for reuse is needed.
> >
> > The Nature of Reuse
> > Reuse is by no means a new concept in IT. It
has
> been tried in various
> > ways and at many levels from the use of
source
> code libraries to the
> > building of software components within
object
> oriented architectures.
> > When left to their own devices, experienced
> developers usually find
> > ways to reuse the code they have previously
> written or even use open
> > source code that is freely available on the
> Internet. But such reuse
> > is never consistent throughout software
> development teams and the IT
> > industry has never implemented reuse
effectively
> in this way.
> >
> > Within the SOA environment reuse is
different
> because it is woven into
> > the architecture. Components of models,
software,
> rules, and data are
> > made available for reuse in a way that
ensures
> their accuracy,
> > consistency and predictability. This amounts
to
> the business
> > governance of all the reusable assets. It
isn't
> easily achieved, but
> > it is a worthwhile goal.
> >
> > The reuse of IT assets is not so different
from
> the reuse of
> > components in manufacturing. Automobile
> manufacturers do not make a
> > different engine for each model of car they
sell;
> they make a small
> > range of engines and install them in a wide
> variety of models. Once a
> > new engine has been tested and documented,
its
> reuse in a wholly new
> > model gets the new car to market much
faster. The
> same is true of even
> > quite small components. Nowadays cars are
designed
> to maximize reuse
> > at every level-and to everyone's benefit.
And just
> as the reuse of
> > components in a production facility needs to
be
> managed carefully, so
> > must the reuse of business services in a SOA
> environment. Reuse
> > without governance can be more destructive
to the
> business than no
> > reuse at all.
> >
> > Hurwitz & Associates has identified three
major
> risks to the business
> > associated with reuse:
> >
> > * Poor Process. This typically occurs when
the
> level of
> > collaboration between business and IT is
> inadequate. Within SOA the
> > business and data services should accurately
> represent the business
> > processes followed by the organization.
> Collaboration between business
> > and IT needs to result in the business
having a
> clear understanding of
> > which definitions of data make sense and
when to
> use them, how to
> > apply rules and what level of granularity is
> appropriate for business
> > services. Effective reuse will be much
harder to
> achieve unless there
> > is a framework in place that ensures that
business
> and IT are singing
> > from the same song sheet.
> > * Poor Management of Code. Business
processes
> are nearly always in
> > a state of flux, so it goes without saying
that
> the software code that
> > codifies a specific business service may
also
> change frequently. When
> > software components are changed then the
changes
> apply
> > everywhere-often resulting in unintended
> consequences.
=== message truncated ===
__________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo!
Autos' Green Center.
http://autos.yahoo.com/green_center/
<http://autos.yahoo.com/green_center/>
