Business Analysis and Stockless Production

Imageby Jason Questor
Founding Partner and EVP Learning Systems

Business Analyst professionals spend a lot of time helping businesses become more efficient through formal or informal process engineering. This may be done within the context of a specific project, or as part of ongoing efforts in continuous improvement.  Because business processes produce value only through the deliverables they create, it makes sense to reverse engineer all business processes from precise definition of those deliverables. Deliverables exist to create value for someone, either the business itself (internal customers) or external clients / customers.  As such, it is through the production of value-centric deliverables that enterprises establish and maintain their reason for being.

An important component of continuous improvement efforts is the identification and elimination of waste. LEAN identifies 9 types of waste:

  • Overproduction
  • Waiting
  • Transport
  • Extra processing
  • Inventory
  • Motion
  • Defects
  • No-value products and services
  • Talent underutilization

When it comes to inventory, you enter the realm of Stockless Production. This is based on the fundamentals of push versus pull.

The basic idea of push versus pull is this. Suppose you are creating a mass mailing. Two of the task steps would be to sign the letter and then fold/put the letter in the envelope/seal the envelope.  And you would have to do these in order (you can’t sign a letter once it is sealed in an envelope). Suppose you have two different people doing these tasks.

  • Person 1: signs letters
  • Person 2: folds letters, puts them in envelopes, seals envelopes. (in fact, this might be considered a task group)

If you look at these two tasks, you will see that the envelope stuffing and sealing likely takes longer to do than just signing. So you would end up with a bunch of signed letters sitting around waiting to be stuffed. And the stack would grow and grow.  So you might go to extra expense and have 2 people stuffing and sealing just to keep up.

PUSH

In a traditional manufacturing situation, the process is based on push. That means that the person signing letters does so with no regard for whether the person folding, stuffing and sealing is ready for another letter.  Person 1 signs a letter and pushes it on to an In Basket for Person 2. The result is inventory (a stack of letters waiting to be stuffed).  Inventory is expensive because it takes up storage space and must be monitored for spoilage (in the case of “best before date” items like food) or damage from just sitting around. Also, suppose the person who needs to sign the letter changes because that person has left the company. Now you have a stack of obsolete signed letters that need to be shredded. This is waste.  LEAN is all about identifying and reducing waste.

PULL

In a pull environment, product is produced only on demand from the person who needs that product. So Person 1 does not sign a letter until Person 2 indicates they are ready for one. This means:

  • Person 1 can be doing other work in the meantime
  • No inventory (which is why this is called Stockless Production)

Many manufacturing companies, such as Dell Computers and Hewlett Packard, deploy stockless production / pull techniques to maintain cost effectiveness. For example, Dell does not build your computer until you order it.

VALUE

The process flow is like a river. Rivers flow downstream.  So the task of signing the letter is UPSTREAM from the task of stuffing and sealing.  Also, the task of signing a letter provides VALUE to the task of stuffing/sealing, meaning that an unsigned letter would have no value if we just stuffed it in an envelope.  This implies that you should never do a task unless the next step in the process gets value from having you do it. When you look at all the tasks together, you create what is called a VALUE STREAM.  You do all of this work to ultimately create value for somebody.

From Business Analysis for Business Performance ©2012 Jason Questor. Jason is Founding President of the Toronto Chapter of the International Institute of Business Analysis, and writes and speaks extensively on the subject.

ACHIEVEBLUE’s Business Analysis Program of Courses can be fully customized  to your organizational needs. Our Lead to Succeed Program includes coverage of LEAN and Stockless Production principles in the Continuous Improvement for Managers course.

Business Analysis and Screen Design: Why and How

by Jason Questor
Founding Partner and EVP Learning Systems

The distinction between requirements and design specifications is a frequent point of confusion for many businesses implementing a business analysis practice.  Where does one leave off and the other begin? This week, while teaching a course on this very topic to one client, another sent me an email asking the same question — “Do business analysts actually get involved in helping to design screens, including the naming of screen components?”  The short answer is yes, but with important qualifications.

An important aspect of business analysis is the formal elicitation, organization and documentation of requirements.  Requirements (needs, objectives, goals) describe the nature of a problem or opportunity, not design specifications, which focus on how you will address and solve the situation. For example, a need may be to satisfy thirst. There are many ways to resolve this (water, juice, soda, etc.). A significant and common issue in business analysis occurs when stakeholders do what is called “solutioning” – telling the business analyst what they want to solve a problem — “I need a Coke®”. What is the actual need here – to satisfy thirst, to cool off in hot weather, to get a quick energy boost from the sugar and caffeine?  In IT projects, solutioning can take the form of saying that the requirement is to purchase a particular product, rather than describing the nature of the need, which could be “I need something that will allow me to track and manage the cost of contracted work”.  Describing what you think is the answer without addressing the question raises the potential of spending money on a solution that will not address an undiscovered need.

An important part of requirements for computerized solutions focuses on the user interface, known as the Presentation Layer. Business analysts do indeed work with users to uncover their requirements for screens and screen components (data entry fields, data retrieved and displayed from databases, on-screen calculations, the labels attached to screen components, etc.) but this is all from the point of view of what is needed, not how it may eventually appear (design).  For example, a user may say “On this screen I need the following information included” and work with the business analyst to the extent of creating screen mock-ups and definitions for screen components – “I need to display the customer’s account balance.  Let’s call it CUSTOMER ACCOUNT BALANCE and the computer will access the database and display that number here.”.

The caveat is that resulting screen mock-up is a requirements prototype not a design prototype. The actual appearance of the final solution may be different based on organizational standards and human factors considerations. Also, the names attached to specific screen components by software developers may be very different due to technology considerations and existing legacy code.  What must be stressed here is that, from the requirements point of view, things like field type and field naming must make sense to the business user, using business terminology, not tech-speak. That same field of CUSTOMER ACCOUNT BALANCE may be referred to as FIELD-2347 by developers and in the actual computer code. It would make no sense to describe it this way to business users, although many failed requirements documents do exactly that, leading to confusion and anxiety in signing off on requirements documents.  Ironically, since the early 1960’s software developers have been urged to use “meaningful data names” (to the business), but even in 2012, that is often not the case.

From Strategic Business Analysis: Building Business Value ©2012 Jason Questor. Jason is founding and current President of the Toronto Chapter of the International Institute of Business Analysis, and writes and speaks extensively on the subject.

ACHIEVEBLUE course BA708: Integrating Use Cases into Application Level Libraries includes extensive coverage on how business analysis practitioners work with users to create effective and efficient user interfaces.