Conference 7.286::digital

1722.0. "CSSE becomes SPE" by SMAUG::GARROD (An Englishman's mind works best when it is almost too late) Wed Jan 15 1992 21:42

    Attached is the reasoning behind the transformation of the old CSSE
    organization to the new SPE. It makes interesting reading. It'll be
    interesting to see if this really helps our level of customer
    satisfaction. I think it will but the jury is still out.
    
    Discuss.
    
    Dave
    
    PS For those automatons with moderator privilege who are conditioned to
       seeing a MAIL header and then deleting/hiding the note please read
       7 lines further into the message.
    
From:	CSSE::SNYDER "Al Snyder CSSE 276-9101  31-Dec-1991 1529" 31-DEC-1991 
15:32:12.27
To:	@SPECSSE.DIS,@DSMC.DIS,@DSEMT.DIS,@PSPEMT.DIS
CC:	
Subj:  	I:  STATE-OF-CSSE/SPE


        *********************************************************
        *  PLEASE GIVE THIS DOCUMENT A "VERY WIDE" DISTRIBUTION *
        *********************************************************





 _ _ _ _ _ _ _
| | | | | | | |
|d|i|g|i|t|a|l|      I N T E R O F F I C E    M E M O R A N D U M
|_|_|_|_|_|_|_|


TO: All Digital Services Functions                   DATE: 24-Dec-91
    Digital Services Clusters and SCUs               FROM: Larry Fox/Al Snyder
    Digital Services Geography Management Teams      DEPT: SPE Management
    Engineering PCU Management Teams
    DSMC
    DSEMT            



Subj: STATE-OF-CSSE/SPE

The attached memo is being sent to the SPONSORS, PARTNERS, and RECIPIENTS
of work that is currently done by the old CSSE and the new SPE organizations. 
The memo is a bit long, but we believe you'll find it worth reading.  Our
goal is to paint a true picture of the state-of-the-organization, and 
to solicit specific help from you to implement our new Serviceability and 
Process Engineering organization.  We believe these changes will help position
Digital Services Engineering to better provide the capabilities that will
differentiate our Service offerings, grow marketshare and profit, and 
yield best-in-class Service Delivery capabilities for our customers.

 State of CSSE/SPE                                                Page 1   
   



STATE-OF-CSSE

Background:

The CSSE organization was created to develop and influence higher degrees
of serviceability and quality into Digital products. CSSE was positioned
organizationally between Engineering and the Field Services groups. In
addition to serviceability, CSSE was best positioned to provide planning
support for service delivery and to provide backup product support to
the geographies for product related problems. CSSE's work was designed
as an integrated component of the Corporate Phase Review Process (PRP) for
the total life cycle management of products. The CSSE organization was
a critical dimension in an environment where there was an inadequate
focus on product serviceability and quality, and the related impacts
to Customer satisfaction along with service delivery costs.

Over time CSSE became successful in influencing product serviceability,
producing effective product plans for geography implementation, and providing
a highly competent technical product support capability. However, starting
in FY89, with the model then used, the Service Business Groups found 
themselves in an increasingly difficult position with regard to available 
funding to maintain the level of CSSE focus required to ensure an appropriate 
level of serviceability engineering, service delivery planning, and product 
support. CSSE Management presented a tremendous amount of justification 
and other related supporting evidence on their needs along with the long 
term impact to the service profits. However, all this could not obtain an 
increase in resources to support the CSSE work model. At best, CSSE was 
able to maintain its "fair share" of the available headquarters funding. 
However, the available funding was shrinking as the company demanded more 
short term profit from Digital Services. In contrast to the reduced amount 
of resources the number of products being produced each year by Digital 
Engineering was increasing. In addition more and more vendor products were 
being pursued as service  opportunities, requiring CSSE product planning and 
support. Following is a brief summary of CSSE headcount since FY88:

   Fiscal Year         Ending CSSE Headcount     Restated to actual CSSE
   -----------         ---------------------     -----------------------
      FY88                      875                     746
      FY89                      810                     681
      FY90                      765                     656
      FY91                      660                     551
      FY92                      575                     486                 
State of CSSE/SPE                                                  Page 2



               
Note:

CSSE has traditionally had a large portion of its headcount associated
with non-CSSE work such as; Technology/R&D, Stow Data Center, CS-IS, 
CLD Management, etc. The restated numbers reflect the pure CSSE work on 
product; Serviceability, Service Delivery planning, and Support.

As you can see we have decreased the number of resources working on 
Digital products and systems by 260 since FY88.

In FY89 CSSE did a zero-based budget analysis, based on the number of 
products being developed by engineering.  This analysis indicated a 
headcount of 1076 people would be needed to do the work utilizing 
traditional CSSE methods. 

So, starting in FY89 CSSE Management began to develop new ways of approaching
its product oriented work to cope with the dynamics mentioned above. A few
of the strategies will be mentioned here:

        o Product Prioritization ... this strategy focused on categorizing
          each product into 3 levels of priority based on impacts to the
          service organization. The lower levels did not receive the maximum
          level of support from CSSE thus allowing the available CSSE
          resources to concentrate on the high priority products.

        o Engineering Product Quality ... this strategy endeavored to 
          get the various engineering groups to do product related work 
          associated with quality and reliability e.g. hardware design, 
          software serviceability requirements, product testing, product 
          support, etc. Some Engineering groups embraced this strategy and 
          began doing more in the dimensions of product quality and 
          serviceability, thus allowing CSSE to cope with reduced levels 
          of resources.

        o Field Self Sufficiency ... this strategy focused on improving the
          technical capabilities of field technical support personnel thereby
          enabling non engineering problems to get resolved in the field.
          This allowed CSSE to transition out of technical support activities
          in some product spaces to allow CSSE management to cope with
          reduced budgets.

During the latter part of FY90 CSSE merged into the newly created Digital
Services Engineering Organization and was immediately challenged to develop
a new organizational model to accomplish the following objectives:

        1. Reduce the amount of required resources significantly.
        2. Accelerate an orderly transition of product level serviceability
           engineering and product support to engineering.
        3. Develop Service Delivery Process Engineering as a discipline.
        4. Support the aggressive initiatives into the MVS market.
        5. Significantly enhance the service delivery systems to support
           the emerging new Customer computing environments, e.g. Personal
           Computing, Distributed Computing, Production Systems Computing.
State of CSSE/SPE                                                  Page 3




To meet this challenge CSSE clearly needed to view its current work and future
orientation from a "New Paradigm". A team of managers from CSSE and other
organizations developed the new paradigm model and introduced a new
organization, Serviceability and Process Engineering (SPE) to respond to
the challenges mentioned above. This new organization and the new work
models and process will leverage off the changes started in FY89. In many
cases the changes required to move from CSSE to SPE simply formalizes the
productivity strategies from past years.

STATE-OF-SPE "The New Paradigm":

As mentioned, CSSE began the definition of "The New Paradigm" concept in FY90. 
This culminated in a proposal that was reviewed with: the Business Units, the 
Geography Management teams, other Corporate functions, Engineering, PCUs, and 
ultimately approved by DSMC in July 1991.  DSMC felt this direction was very 
much in line with the direction of the company and Digital Services.  It 
embraces several key concepts: the New Management System (NMS), the Four 
Business model, the Cluster versus Functional roles in Digital Services, and 
the creation of a Digital Services Engineering Organization.

In summary, the New Paradigm addresses 5 key areas of focus for SPE:

    1. It recognizes that there is more than one computing environment 
       (VAX/VMS), as seen by our customers.  We've identified four: 
       Personalized Computing, Distributed Computing, Departmental (the
       traditional VAX/VMS), and Production Systems.  

       Digital Services Engineering accepts the responsibility to define
       the Service Delivery Vision and Architecture for the future that
       addresses the customer needs in these computing environments, as
       well as the business needs of the Clusters and Geography Service
       Delivery Organization. 

    2. It rationalizes that customers have different needs in each of these
       environments and that our Service Offerings and Service Delivery 
       processes should match these needs.  Many customers will have 
       multiple environments and will need scaleable services. 

    3. It recognizes that Digital Services must do a much better job 
       at defining, engineering, releasing and supporting the Service
       Delivery processes for these environments.  

    4. It identifies the new SPE Organization as the group responsible for:

        o The engineering of Service Delivery Processes that meet 
          the customer and Business Cluster needs.

        o The development and release of industry standards for Serviceability.
          This may include the selling of consulting services for 
          Serviceability design to cooperative vendors.

State of CSSE/SPE                                                  Page 4





        o Specifications for Serviceability Engineering against product 
          technologies (families) versus point products that can be implemented
          by all Engineering groups in the industry (DEC and NON-DEC).

        o The development of Product Based Service Tools such as SDD.

        o The release of these Service Delivery Processes; a complete process
          will identify, "the process that people implement, utilizing
          information, tools, and parts". 

        o The Continuous Improvement Engineering for the above deliverables.
          Since we view ourselves just like any other engineering organization,
          we must accept the responsibility for the products and processes we
          release.  We will apply TQM as a means for continual improvement. 

    5. Additionally, we have chosen to integrate Corporate DSL-Engineering work 
       on Repairability Design and  Repair Process Development into SPE.  This
       group will also do select product improvement and value added work, such
       as major consumption reduction programs.  These programs will be ROI
       based and sponsored by a SCU. 
       

In support of the above goals, SPE has developed a set of Purpose, Mission, 
Objectives  and Goals (PMOGs) that respond to the business direction set 
by the Digital Services Clusters and Service Creation Units. These PMOGs
are available to anyone in Digital, upon request.  

Organizationally, SPE is in the process of implementing a Program/Resource
management model.  We will have two types of dedicated Program Managers;
one group  will focus on the Computing Environments, and one on the Technology
Domains.  The Environmental Program managers have the responsibility to
work with the SCUs, the Geographies, and other D.S. Functions to develop
the customer requirements and Service Delivery response for each environment.
The Technology Program Managers are responsible for developing the Service
Delivery Processes and Serviceability requirements for their technical domain.
They will respond to the needs of the Environment, but will be closely 
coupled to the PCUs and/or non-DEC vendors for MVS service needs. The 
resource managers are responsible for carrying out the SPE work.  

TRANSITION ACTIVITIES:

SPE management wishes to strongly communicate to our funders, co-makers, 
constituents, and customers that we are not going to simply stop the 
old CSSE work and move to the "new work paradigm" without your participation, 
help, and buy-in. 

We are going to manage our transition from the historical CSSE work methods
to our new SPE work methods in a way that ensures that neither you nor we 
will fail to achieve our goals due to this transition. Additionally, we want 
to ensure that you, not only understand the concept of the new work paradigm, 
but also realize tangible benefit to Digital Services, Digital, and most 
importantly, our customers. 
State of CSSE/SPE                                                  Page 5




We have three primary factors that are driving these changes.

    1.)  The Service Creation Units could no longer afford to operate
         under the traditional model (as mentioned above).

    2.)  With this as the driving factor, we must carefully divest 
         ourselves of some historical CSSE tasks  which, according to 
         the principles of the New Management System, rightfully belong 
         to others.   This divestiture will be done  carefully, with the 
         participation of those organizations and functions who will be 
         asked to pick up or agree to drop some historical work areas.


    3.)  We will change the way we do much of the remaining work that does
         relate to serviceability engineering and service delivery process
         design.   Most of these changes will involve changes to the
         "envelope" of what we deliver, and not diminish the content of
         what we deliver.   Indeed we hope to greatly improve the content.
         We will eliminate some historical CSSE tasks that were identified
         as low value by our funders and/or customers in the Services
         community.   The elimination of such tasks should have no
         negative impacts to the PCUs or other functions.

FUTURE PLANS:

The issues involved in this transition are critical, not only to ourselves, 
but to PCUs and other affected functions.  The rationale for changes in 
these responsibilities is based in the principles of the New Management 
System.   We have been organizing our own thinking on these issues in a 
set of task forces within SPE.   

We are now at the point of inviting the active involvement of other functions 
and organizations in planning out the appropriate transition of 
responsibilities in these areas.   This cross functional work is planned to be
focused in task forces on such areas as Product Support, Product Information
and Communication, Product Qualification,   Field Readiness,  Business
Relationships, etc.  We have recently solicited for participation
in these task forces to the Engineering groups, the SCUs, the Geographies, 
and others.  Our goal is to finalize the details of the transition process 
during early Q3 and review each and every point with the affected parties 
and ensure they buy-into the process. 

We have developed a master plan to ensure a smooth transition.  This master 
plan consists of a 26 point task list, with DRIs assigned to each task, 
and is available to anyone in Digital, and we would greatly appreciate 
comments and feedback for improvement from all interested parties.  Please 
contact Shirley Bausch (OGO) or Cherie Hastings (ZKO) for the most recent 
copy. 
State of CSSE/SPE                                                  Page 6




Much of this work has already been reviewed with key individuals in these
organizations. This has greatly helped us to prepare, but unfortunately,
it has also caused some confusion with others who are not as close to the
process. The Product Support Proposal is a primary example of this.  
Ultimately, all the top level issues will be coordinated and reviewed 
with our co-makers, funders, and customers so that SPE is able
to do an orderly transition, in a consistent way, around the world.  
It is to this level of tasks that the management team has committed that  
"No work will be dropped until an agreed upon transition plan has been put 
in place". 

Beneath this top level, is another level of tasking that is also very 
much in motion.    This is at the level of the day to day tasks of current 
CSSE personnel doing their historic tasks.   We have encouraged our entire 
organization to participate in this level of work.  As part of our 
re-focusing on serviceability engineering and service delivery process 
engineering, we are actively seeking to identify:


    a) Tasks in these areas that we can do more effectively and efficiently.
       This is work that "must" be done, which SPE will continue.  We are
       seeking to improve the cost effectivity of doing it.  We expect to
       "change the envelope" of our delivery of much of this work, while
       improving its content.

    b) We have found many tasks and work methods that we have been doing
       more out of historical precedent and momentum rather than any real 
       present day business need or benefit. Additionally, many of these
       tasks are viewed as low value added by our funders. Tasks  of this 
       type we intend to discontinue immediately.

We believe that through some unintended confusion in our communications, that
we have allowed some of our people to confuse some of the work described in
item "b" above with work that legitimately belongs in the other categories.
That is how you may inappropriately hear "We are going to stop doing thus and
so...."   applied to work that is deemed critical to your operations.  We
apologize for such confusion and will correct those problems.

SUPPORT REQUIRED: 

SPE Management will require support from virtually all the Digital 
organizations involved with CSSE. This support is critical to enable
the realization of the New Paradigm, allow SPE to meet its financial 
constraints, and to maintain the SPE work-force. Following are the key
requirements for support:

        o Geography Service Delivery ... accept the responsibility and 
          ownership for product self sufficiency. This means seeking out and 
          implementing the plans to support new products so as to achieve the 
          ability to handle all calls from Customers which are not engineering
          design related problems. Being open to working with SPE and 
          Engineering to develop and implement new processes and information 
          flows which enables geography service delivery to work directly 
          with engineering.
State of CSSE/SPE                                                  Page 7




        o Service Creation Units ... understand the significant dilemma
          SPE is in at present with still having responsibility for old CSSE
          work, development/buy-in for transition of appropriate old CSSE 
          work, and the increasing requirements for new SPE work methods, 
          helping to provide  assistance to balance these conflicting 
          priorities. Additionally, we need you to drive new Product 
          Management processes which will enable SPE to get out of the 
          middle between SCU Product management and PCU Product management.
          Finally, we need help to integrate and coordinate requirements
          for new or enhanced service capabilities.

        o Engineering groups ... accept the product related responsibilities
          associated with product quality, RELIABILITY, and serviceability. 
          Work with SPE to develop and implement new processes and information 
          flows  for product management and planning.

        o Other DSE Functions ... recognize and support the SPE Computing
          Environment Programs.


In closing, we would like your help, feedback, and suggestions to ensure
customer satisfaction does not diminish during this change.  Feel free to
contact any of the individuals below if you have concerns, ideas, or
questions.  Thank you for your understanding and support.


  NAME           LOCATION                    DTN            NODE

Larry Fox       ZK01-1/C30                381-0786         CSSE32::LFOX

Don Herbener    OGO1-2/E16                276-9154         CSSE::Herbener

Al Snyder       OGO1-2/G16                276-9101         CSSE::Snyder
                CXN2-35                   523-2166

    How come the digital logo is without the "TM" next to it?

    
    What does SPE mean?
    

    From an ex-CSSEer's perspective, there were 2 main problems with the
    above plan (which was first announced back in August).
    
    	The 1st was that up front we were told that 55% of the current head
    count was not going to be in CSSE by 7/92, and that those who stayed
    would effectively be doing paperwork, or coming up with plans with
    absolutely no authority to implement them.  There was a real
    implication that those who did not make the cut would be cut.  This
    led to a failry rapid exodus of much of the technical talent in the
    current CSSE org.  Thus the engineering groups were left with no
    experienced people to draw on once they owned product support.
    
    	The 2nd was that CSSE product support had made very great strides
    in problem resolution over the past year and a half.  We had gotten
    hundreds of people well trained, and a failry smooth organization in
    place.  Sure there were problems, but they seemed to be slowly working
    themselves out.  This new paradigm required that all of that work be
    thrown out.  In the very long run, the idea could produce great gains
    in product quality; but who has ever heard of an idea last for the very
    long run.
    
    	My cut at this was that two CSSE managers became enamoured of
    the 6-sigma concept of paradigm shifts.  Although this concept is
    valid, these two managers took it to it's logical extreme:  "If
    shifting to new paradigms is a good thing, let's do it!"  Thus their
    real new paradigm was:
    
    	"The paradigm of shifting paradigms."  What this means, of course,
    is that our customers are going to continue on the great roller-coaster
    ride of product support.
    
    	Good luck to all of us.
    
    	Peter (who is now very happy in an engineering group un-related to
    the space he came from in CSSE).

	Re .2
>>    What does SPE mean?

	To quote from .0 ....

	" ...... to solicit specific help from you to implement our
	 new Serviceability and Process Engineering organization."
	     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Re .4
    
    	Of course, there is the next logical question:
    
    What does "Serviceability and Process Engineering" mean?
    
    peter

  Re .3 (Peter)

  > This led to a fairly rapid exodus of much of the technical talent in
  > the current CSSE org.  Thus the engineering groups were left with no    
  > experienced people to draw on once they owned product support.      

  This was very noticeable in the field for some products - the few who were
  left were/are incredibly overworked and the knock-on effect is a source of
  much customer dissatisfaction [ in addition to that felt by field support
  and excess pressure on the CSSE engineers who are trying to make the best
  of a ridiculous situation ].

  Frank
  
  "Serviceability and Process Engineering" = "We engineer the figures to
  show that the process works whilst letting someone else worry about
  service" ? Or have I got that wrong ?

>Of course, there is the next logical question:
>What does "Serviceability and Process Engineering" mean?

That's what CSSE does.    :-)

    
    re .7: a succinct and accurate description of the problem...
    

Re:                    <<< Note 1722.1 by STAR::ABBASI >>>

>    How come the digital logo is without the "TM" next to it?

Probably because it's not an approved logo!  It's amazing how frequently I see 
unapproved ones coming from "upper management"...

I think this has been discussed elsewhere in this conference, but the approved
one for ASCII text is: 

		+---------------------------+ TM
		|   |   |   |   |   |   |   |
		| d | i | g | i | t | a | l |
		|   |   |   |   |   |   |   |
		+---------------------------+

-  David