iSixSigma

Manufacturing v Transactional

Six Sigma – iSixSigma Forums Old Forums General Manufacturing v Transactional

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #41379

    Iain R
    Participant

    As a 5 year BB with 20 years manufacturing experience, I have the opportunity to move out of manufacturing into a purely transactional industry.  Whilst I am confident that all my experience, and application of both Lean and Six Sigma will transfer nicely  –  I have no experience of it.
    Is my confidence justified?  What potential problems (and I assume data collection and accuracy is one) would I have in applying my experience in a transactional project?  Any views appreciated.

    0
    #129610

    OBTODT
    Participant

    I take the approach that it’s all a process.   Your point that empirical data is not always as readily available in a transactional process as a manufacturing process is valid but it should not deter you from looking at the transactional process as a stepwise assemblage of actions each with wait and queue times, either having requisite sequential inputs or not, etc.   Lean tools such as Value Stream Mapping can give you a foundation for transactional process dissection, improvement and re-assemblage to a better state.  
     
    One of the key things I tell my Black Belts when they move into transactional projects is to look at the tremendous opportunity it presents them and the corporation because the manufacturing areas have been mined for process improvements for years (although it’s an ongoing process and I believe improvements can always be made in manufacturing) but the overhead transactional areas are fresh new red meat of opportunity since, for the most part, senior management views them as either running or not, looking for the presence of anomalies or derailings or not, but always through the same self-confirmatory lens of the process creator/owner – it’s running as I set it up so it must be right….  Self-fulfilling prophesies can provide for treacherous BPI waters.   
     
    I’d say that you should take the tools and knowledge that you have acquired and used well over the past 5 and 20 years and continue to look at your new opportunity as process improvement, i.e., gathering data, using tools, performing analysis, and effecting change, as you did in your manufacturing assignments – with the understanding that your tool selection and past somewhat rote use of tools is changing to a more creative bend because solid empirical data will frequently be sparser and softer than desirable for a data-cranking manufacturing guy.
     
    My opinion anyway.   
     
    OBTODT
     
    (Occasionally Been There and Occasionally Done That – but admittedly not as well as the real BTDT)

    0
    #129611

    cheezer
    Participant

    OBTODT does a good job explaining the differences. I’d also add that transactional areas can be politically more sensitive, as these areas historically haven’t been measured like mgf at the process level. Also, the process owners are often a few steps up on the ladder, with more influence and power.

    0
    #129614

    NS
    Participant

    This is the way that I look at it.  In most of our plants, 5-10% of our activites are Value-Added.  Yet, we spend a great deal of time trying to improve/optimize the 5% VA steps.
    With a Process Analysis or Transactional approach you get the chance to directly impact 90-95% of the process.  These projects usually yield a substantial amount of cash in a relatively short period of time.  You should jump at a chance to work on these types of projects.  The tools that you already know (mapping, spaghetti diagrams, VA/NVA, etc. will be of great value to you).
    The previous comments are insightful.

    0
    #129621

    BTDT
    Participant

    OBTODT:

    OBTODT:The biggest difference in transactional vs. manufacturing is
    that:
    inventory
    is invisible and is hard to quantify in terms of cash flow
    there
    are differences in the magnitude of time required hand-offs between the
    subprocesses.
    Let’s look at transactional processes in more detail.The usual feeling is that when something is completed by
    process A, then it is not yet ‘owned’ by the next step in the process. Things
    fall ‘between’ the cracks, and process B can just as easily claim that there is
    missing information (not B’s fault) and put it on hold awaiting the missing
    information that never comes from process A (because they are on the next
    thing). These transactions fall into a never-never land of “is it WIP, or
    rework?” and it becomes hard to classify these transactions.The impact of errors in transactional projects is that the
    difference between an approval process (5 minutes) and a re-worked approval
    process (2 days in someone’s IN box) is huge. This large a difference is not
    usually seen in manufacturing and is usually much fewer pieces (transactions).The approach to transactional projects is not so much VA/NVA
    analysis as it is about mistake-proofing subprocesses and making sure problems
    are fixed within the subprocess and not re-routed back up stream.Adam Bowden identified the causes of missing information during
    the application process for mortgages. This allowed him to define information
    that was absolutely required from the customer during the initial application. He
    implemented this using mistake proofing. This eliminated the steps of identifying
    and obtaining missing information as the application proceeded though the
    process to the final step of forwarding funds. The turn around time for
    applications went from weeks to minutes.Cheers, BTDT

    0
Viewing 5 posts - 1 through 5 (of 5 total)

The forum ‘General’ is closed to new topics and replies.