Conference 7.286::digital

I personally have a very hard time understanding why we think that
a customer will pay us to go out and hire contractors from a consulting firm.

Do we think that they are not sophisticated to establish those relationships on
their own?  The set one up with us, why not with ABC consulting?

Do we have the audacity to think that customers will hire us when the only
differentiator is our wonderful management?  I worked too many years in Digital
Consulting to believe that.

This has been coming for awhile, and when it hits the fan there are really only
two choices:  Recognize what it takes to do consulting right, and do whatever it
takes (tm), or watch the business dry up, and fold up shop.

Kevin

    
    FWIW...
    
    Partners (including Integration partners) now deal with engineering.
    
    So what does Digital SI w subs bring to the table that a partner can't?
    
    How long will it take a customer to figure out they can go straight to a
    sub?
    
    If Si continues to sub, how long will it take the sub to figure out
    they can go to engineering, and cut Digital SI out?
    
    Is Digital SI in effect giving away the business when they sub now?
    
    Is Digital SI business now finding/selling/managing SI via subs?
    	Perhaps we won't deliver anymore?
    
    Its a brave new world.

    
    I agree with .1 & .2 
    
    I think that many customers are already seeing how thin our ranks
    really are and are making decisions about the "value" versus the cost
    of the Digital "middleman". On one recent project the ENTIRE project
    team of eight people turned over within twelve weeks, three of them in
    one week. NONE were TFSOed, they were all recruited to better paying
    jobs. The project was completed on time. We lost the follow-on
    business ($2.3 million), anyone wonder why?  
    
    These days I look at an SI opportunity and ask myself:
    
    	Will I be able to marshall the right skills in time to respond on 
    	time to the customer?
    
    	When I add my margin and risk to the Sub-contractor price will my
    	price still be competitive? In fact, when I look at the Digital 
        content is the risk worthwhile?
    
    	In spite of all that, if I win the business will I have even the
    	minimal Digital resources available to deliver even the small part
    	of the project we committed to deliver ?
    
    Do we really believe that our customers aren't smart enough to
    figure this out? Even if they aren't, there are now more ex-Digital
    consultants out there than we have remaining telling those same 
    customers the good news on behalf of their current employers. 
    
    The real danger is that when WE aren't driving the SI business WE
    aren't going to be able to control the selection of the solution
    components the way we would like. When we aren't on site delivering it
    won't be us ferreting out the follow-on business. When we aren't the 
    ones whose work is the most visible who will they call the next time?
    
    JLB

    I am a SI field manager. In my geography we use sub-contractors once in
    a while to supplement our staff. We never use them in lead roles. 
    
    I am getting excellent support for recriuting and hiring externally to
    fill critical needs.
    

re Note 3778.3 by LIOS01::BARNES:

>     The real danger is that when WE aren't driving the SI business WE
>     aren't going to be able to control the selection of the solution
>     components the way we would like. 

        This may be especially damaging since our software strategy
        is middleware-based, a natural for mutual leveraging with SI.

        Bob

    
    DECmessageQ ( a middleware product) benefited in the past from
    large SI projects with DEC as the prime.  Such projects are 
    a thing of the past.  We have been kludging our own SI - presales
    consulting for important accounts, but the people who can do this
    and are available to do this we can count on one hand.
    
    What is really annoying is that there is PLENTY of SI business
    out there.  Somebody can get RICH just bottom feeding, never
    mind the big enterprise stuff.  And the big enterprise sales
    are hugh if you land them.
    
    I believe that the old model of failure in the SI space was 
    not due to lack of technical ability in the project teams, rather 
    it was due to inappropriate metrics that encouraged and rewarded poor
    management. Lack of a reality check on pricing did not help
    either.  But what we have wound up doing is losing or scattering
    the technical people, in the rush to run away from this space.
    
    Does anybody read this who can do anything about it?  
    
    

    re-1 I doubt it and I doubt that if they did they would care.
    SI is effectively dead for us-not because there is no market but
    because we have never taken it seriously and defined where we would be
    good.Cap it off with organisation changes,lack of leadership and
    metrics and here we are.
    Do you know anybody these days who would commit the organisation as you
    are expected to do in SI?Do you know any generic systems
    integrators?No,they are all vertical market specific or at least highly
    knowledgeable-this is a dirty word in the current organisational state.
    Pity but true..
    

         You have to ask yourself why Digital does SI at all.  Is it 
    because we do it better?  ... or because it's expected of us?
         
         You'd be hard put to argue that we do it better, at least 
    managerially.  DPM seems to be on permanent hold since recently and 
    most of us could say where and how our processes and systems could be 
    improved.  I'm thinking of things like Pert planning, risk manage-
    ment, quality management, reporting and billing, sub-contractors, 
    document management, work flow and on and on and ...
         
         Let me stress that technically I think our people cannot be 
    bettered.  But managerially ...
         
         So I guess "It's expected of us."  There are some customers who 
    still value a single-source contract with a reliable supplier and I 
    suppose we still qualify as reliable.  If what we bring to the party 
    is our financial standing, why wouldn't we use sub-contractors?  They 
    have lots of advantages, especially here in Europe.  You don't have 
    to pay them redundancy, you have a larger choice, they look after 
    themselves in terms of taxes and other gu'mmint business, you don't 
    have to pay for their training, or vacation.  And they appreciate the 
    business as opposed to the competition from a would be SI shop.
         
         SI for Digital is a necessary evil; the price of getting more 
    systems business.  Otherwise the two are totally different and no one 
    in their right mind would try to combine them.  In terms of invest-
    ment, man management (we still talk dirty like that over here), one-
    off versus run-rate, selling cost versus revenue, profitability etc. 
    etc. they could hardly be further apart.  We do SI because we have to 
    to sell systems but all we need to put up is our name and standing, not 
    a regular army of full-timers.  Now it's another interesting question 
    whether we would lose* or gain business by just saying "No! Go to EDS."
    
    (* Please note this spelling.  And while I'm about it, "kudos", 
    pronounced "Q-DOS", is singular!)

    Good analysis.I don't agree that SI is a necessary evil for the sake of
    getting more systems business.I think it is a necessary evil to keep
    people employed and nothing more.If we concentrated on high volume
    systems business only and dropped all pretence of this game of charades
    that we call SI,then we might turn into the high volume,channels
    orientated technology company that some people want.
    You can't get away with generic SI for long and we only offer poorly
    resourced generic SI these days.If an 'executive' decision was made to
    focus more,then we would be OK-clearly a seperate division would be a
    good idea but we would put the same management in so...
    The other alternative is to get out of course but the impacts on
    headcount and morale would be a bit much.It looks to me like we ARE
    getting out anyway and putting resources into sales support.
    You see,it is a simple problem of defining what you want to be when you
    grow up-the trouble is you shouldn't change you mind every week.
    
    I would offer to run SI worldwide at ZERO salary for three years with a
    payoff of 1% of the added value(at current goals)at the end on condition
    that I had carte blanche- but who could give the carte blanche?
    What about it Bob? 

re: .8
         
>>         SI for Digital is a necessary evil; the price of getting more 
>>    systems business.  Otherwise the two are totally different and no one 
>>    in their right mind would try to combine them.

I beg to differ.

I would argue that one of the few reasons that Digital has an advantage over
SI houses or other computer vendors is precisely the opportunity to combine
SI and systems work.  [A colleague of mine joined Digital from Arthur Andersen,
because he saw this advantage.]

There are two kinds of examples:

 o ALL-IN-1

   This product started as an SI project for Dupont in the U.S.  It was 
moved from the Field to Engineering as a product, and we made a lot of money 
from SW, HW, and service.  [Please don't take the "and" to mean "as a
consequence".  I am simply pointing out one method of combining SI and
systems business.]

 o Opportunities for developing/fixing/modifying our systems products

   Engineering can and should build products in the context of SI projects.
This permits understanding product requirements in a real context (building
things customers want to buy, rather than building things engineers want to
build) and figuring out what the products are like when customers actually try
to use them  ("You mean you have to do THAT to get these systems to
communicate!!!!!").  I can dredge up a personal example from the dim, dark
past for DECnet Phase 1.

The problem is that we are not in fact taking advantage of our capabilities. 
In my not-so-humble opinion, the people who run the SI business do not
understand that we have this advantage; furthermore, the metrics for 
Engineering and SI work against the combination.

- Scott

    I'll take exception, also here.  Every day I work with clients figuring
    out how to integrate their systems with Digital.  The DEC/EDI
    (Electronic Data Interchange) product is a client/server product with
    clients that run on HP, IBM, and various Digital platforms.
    
    One of the biggest selling features of our product is that it's a Leggo
    set, meaning the user can configure it as fits their needs.  Our
    competitors still run on the "Big software run on single Box" theory. 
    Makes it hard for them to compete when we say "We'll integrate your
    entire business for EDI, save you money, and this little high-speed
    Alpha (box only) is what will do it."
    
    I *do* agree there's no cohesive direction from upper mgt for SI. 
    Until that arrives in pamphlet form, our group sets their own.  That's
    selling Digital hardware, software, and services by ensuring the
    customer's needs are met, whatever their hardware/software solution is.
    
    (In the past, our group has tuned IBM mainframes, when necessary! 
    "Whatever it takes".)
    
    								Tex
    
    As Mark Twain said, and I think it applies to SI, "The rumours of my
    demise are greatly exaggerated".

    re:SI being dead

    	Systems Integration, as far as I can tell, still means different
    things to different people. The group I work for used to be called
    Systems Integration Engineering. At the time we did POM, benchmarks,
    and proof-of-concept testing. The POC is your one-off test (as it was
    called) and is to show whether a specific selection of HW/SW can work
    together to solve a particular problem.

    	Although our groups name has changed, we still do proof-of-concept
    testing and benchmarks. We have about 20K square feet of lab space in
    NIO alone, and roll-over equipment procurement capabilities. We can provide
    anything from rental equipt./lab space, to full consulting capability.

    	I've also done work for a group in NIO called Value-added
    Integration Services (VIS). They essentially do a more advanced form of
    FA&T. They pull all of the HW and SW together in one place, set it up,
    test it, demo it to the customer (if need be), and actually travel out
    to the field and install it (if the customer purchases this service).

    	Between these two groups, they cover most peoples definition of
    Systems Integration. VIS can handle SI projects where it is known in
    advance that the HW/SW will work together. They provide the integration
    but not the engineering of the solution itself.
    
    	The group that I'm in (Enterprise System Engineering) can provide
    the integration and the engineering for large scale SI projects. SI is 
    not dead in Digital, it's just probably not as well known/publicized as 
    it could or should be.	
    
    	Ray

    re: .12
    
    When I write about System Integration I mean a turn-key solution
    including for instance components like:
    	project management
    	procurement	
    	design
    	development
    	installation
    	training
    	acceptance
    	support
    	Digital hardware
    	Digital software
    	network
    	third party hardware
    	third party software
    	
    I think .12 was referring to a sub-set of the above.
    
    Thanks for the feedback so far. I am still feeling my way into this
    business.
    
    Mike

	Our group does system integration also. We build servers. Our
	first one is the Internet Alphaserver. Our next will be
	pretty neat :-).

	Our system integration is taking all the dissimilar parts and
	putting them all together (hardware and software) so a customer
	doesn't have too and in such a way that a VAR can resell it.
	There is a definate market for that. In the case of the Internet
	Alphaserver, a customer wants a solution and a VAR wants something
	he/she can customize. Neither want to spend the time/effort/money
	surfing the net for all the bits, figuring out how to get them
	all compiled, and then designing a user interface to easily
	manage the system. Give them that tho, and they add all sorts
	of stuff to it. (training, new html pages, etc...)

	You don't have to integrate soup to nuts. You can let the VAR
	add the garnish and set the table while you cook in the kitchen.
	So long as the customer is happy.

							mike

    re:13

    	We've been involved in projects that cover all of the aspects
    mentioned. There have been a couple projects in which Digital people
    actually ran the system for the customer while providing OJT. Digital 
    even procured (leased) and prepared the building in which the solution
    system was placed in. Can't get much more turn-key than that.

    	One of the problems with doing the one-off sort of projects is in
    reselling the solution, or even learning a significant amount from it
    that can be usefully carried into other projects. For large scale one-offs
    requiring massive amounts of hardware, it is fairly difficult for any
    outsider to compete with Digital where the solution consists of mainly
    Digital hardware.

    	When the solutions are small and/or include quite a mix of third
    party HW/SW, there is much more opportunity for competition from
    outside SI shops.

    	The real trick is to find the solutions, such as the one mentioned
    earlier, that can be replicated and sold in an almost cookie-cutter
    fashion. You create them, provide the documentation/support for them,
    and move on to the next (in an ideal SI scenario ;-).

    	Ray

    re .15
    
    I don't suppose you would include in that a DMQ-based RPC system that
    uses C header files for IDL (interface definition language) and has
    been inserted into existing applications without (much) re-writing,
    would you?

    re:-1
    
    > I don't suppose you would include in that a...
    
    	Include in what ? If your talking about a solution that needs 
    X done, anything can be done for a price. 
    
    	Ray

>anything can be done for a price. 


...which has always been Digital's SI motto...and probably the biggest
reason why we have failed in this market...

tim

    	If a customer asks us to do something, and we can attach a
    *realistic* price tag to it *and* deliver the solution in a specified
    timeframe for the specified price, then everyone wins (at least in theory).
    
    	In reality what seems to happen is that the price is too low because
    the amount of labor is underestimated (either accidently or intentionally),
    and the solution is either late, doesn't match the original requirements, 
    or can't be done at all.
    
    	The "anything for a buck" wouldn't be killing us if we were actually
    making the proverbial "buck".
    
    	Ray

    re .17, .16, etc.
    
    >> I don't suppose you would include in that a...
    
    > Include in what...?
    
    Odd, my wife tells me I'm always starting conversations midstream,
    without context.  Sorry.
    
    My entry was probably intended as a response to the comment on
    "solutions...that can be replicated and sold in an almost cookie-cutter
    fashion."
    
    We have created a DMQ-based RPC system (VMS, at the moment) that we
    have slipped into an existing 3rd-party manufacturing work instructions
    system (with the 3rd-party's help) and that is being used for the next
    phase of a customer's development effort. I'd like to see it used
    elsewhere, if possible, so we can make some (more) money off of it.
    (Oddly enough, the customer would like the same: the more users, the
    more support, the more stable, I suppose.) 
    
    The complete question, in some context, would be: "Is this the sort of
    cookie-cutter system you might be talking about, or are you looking at
    the 'Intro to Client/Server' packages we're supposed to be pushing?"
    (Or that we were pushing last year? whatever)
    

    re .1
    
    >We have created a DMQ-based RPC system (VMS, at the moment) that we
    >have slipped into an existing 3rd-party manufacturing work instructions
    
    
    I thought that DMW (reliable messaging) and RPC (remote procedure call)
    were two different communications models for building client-server. I
    also thought that in most cases either one could do the job by itself. 
    Could you explain what problem you solved using both?  ALso how is the
    performance in messages or rpc's per second? What parameter or
    message size? Maybe I could use it if I knew more about it.
    /joel