Posts Tagged ‘Screw manufacturing’

Engineering Vs Business Requirements Gathering

Tuesday, August 19th, 2008

Is engineering a screw same as requirements gathering for a supplier software? Let us look at it in the following categories

    1.Pain: ‘Who has’ or ‘What are’ the major issues:
      a. Software: A list of major issues that people who are going to use the software will face.
      b. Manufacturing: A list of major issues that will arise by using this screw to join two machines.

    2. Interdependencies: Who or What will be affected by each of the issues:

      a. Software: For each issue identified by the business user who else in the organization, gets affected directly or indirectly if this issue is not resolved. This will help the software to account for related functionality that may be needed by other business users.
      b. Manufacturing: For each mechanical issue created by joining the two machines which other component in theses machine will be directly or indirectly affected if there is an issue with the screw. This will help in identifying all the vibration, ware and tare on moving parts, and other considerations that is needed for engineering.

    3. Security: Who or What can access this:

      a. Software: Which user has rights to add, update or delete information?
      b. Manufacturing: Which sensors or parts and under what condition should interact with the screw. Should there be a sensor on the screw to stop the functioning of the machine under vibration reaching maximum value of frequency weighted acceleration (m/s2).

    4. Existing System: What logic or parts can be leveraged of the existing system?

      a. Software: What are the existing business logics that can be leveraged from the existing system?
      b. Manufacturing: Is there existing material or mechanical interface that can be leveraged to connect the two machines with this new screw?

    5. Changes: How and what needs to be considered today for future changes.

      a. Software: How is the business going to change in the next two to five years? This will help in creating interfaces for the software to connect to other software system for future use.
      b. Manufacturing: How will the usage of this machine change in the next two to five years? This will help in planning and designing a standard connectivity interface (screw) so that future re-engineering can be reduced.

    6. Prototype: A non-working model to validate the screw or the software.

      a. Software: A whiteboard method can be used to show the business users how the information will follow and what they will see on their screen. This will help in identifying new requirements especially in prioritizing information that needs to be seen before other information.
      b. Manufacturing: A non-working prototype will help with further analysis of the strength of materials, locking mechanism and other factors that will relate to manufacturing of this screw.

    7. Processes: Where and how does this software or machine fit in the organization?

      a. Software: In the business process flow where does this software fit, which process is this software going to help improve efficiency, does this software get input from another process and/or feeds it’s output to another business process. These questions help in identify how this software will be used.
      b. Manufacturing: Where in the manufacturing process this connected machine will be used, is this going to be used in a linear progression layout or others? This will give the engineer the knowledge on how this resulting new machine is going to be used and the factors that may impact the screw based on the input and output.

    8. Rules: Is the software or the manufacturing governed under regulatory rules.

      a. Software: If an organization is governed by a regulatory body then the software may need validation and other specific requirements that may need to be implemented functionally into the software, to satisfy the regulatory requirements.
      b. Manufacturing: In manufacturing the same will hold true, especially when dealing with heat generating machine or other electrical components. This will lead to putting right labels on the resulting machine after they have been joint using the screw.

Is making software same as making screws?

Friday, April 18th, 2008

Me & my coauthor Let us discover the answer to the above question over many blogs. In the blogs I will outline what is needed when a manufacturer manufactures a screw and compare it to software development, or selection process for custom or off-the-shelf software.

On the surface the two looks to be the same. Following are high level steps for both:
Manufacturing:
1. Problem Statement: What is the screw needed for?
2. Design and Engineer the screw: Specify material, dimensions, angles and more
3. Forecasting: Forecast the demand of the screw.
4. Costing: Calculate the cost of manufacturing the screw.
5. Manufacturing process: Identify if Grid, Putting-out, LEAN, Agile or other processes.
6. Manufacturing the screw: Setting up machines, supply chain, material movement and others.
7. Quality Control: stress test, regression testing, Six Sigma, GAMP, SQC or others
8. Delivery: JIT, On-Demand, Bulk or others
9. Engineering Changes

Software:
1. Problem Statement: What is the goal of the software?
2. Requirements: Specify functionality, security, scalability and more
3. Forecasting: Forecast the install base.
4. Costing: Estimate cost using Function Point Analysis, Manual or Automated estimation or some other estimation tools.
5. Software Development Methodology (Manufacturing process): Agile, Waterfall, Spiral or other methodologies.
6. Selection/Development of Software (Manufacturing the screw): Select applications/ languages, developers, databases, and installing/programming the software.
7. Quality Control: Black/White box technique, Unit testing, Statistical process or others
8. Delivery: Push/Pull, SaaS, Thick/Thin Client, n-tier delivery or others
9. Requirement Changes: This is same as engineering changes.

So let us see if this is true by using a Story:

Quest (Problem Statement):
Manufacturing:
In 1990, I was busy working with modifying equipment that we had imported from Italy. The issue was we were missing screws that would make two parts of this equipment work together, and hence our quest began!

Software:
In 2000, I was working to implement software that will help all the suppliers feed in data so that the company will know exactly how much inventory they needed per supplier. The issue was to find out if there was software that can connect all the suppliers, and hence our quest began!

Realization we need help:
Manufacturing:
What kind of screw and what dimension? We were laterally joining two machines with two very distinct functionalities. Considering many options to see what will work, left over screw pile from other jobs, go to the hardware store and get the screw and other options. After trying many things that lead to incorrect fits, we had to go back to the drawing board to see what we were trying to achieve. After much debate we got an engineer to design the screw that will solve our problem.

Software:
In 2000, there were many options available for us for supply chain integration. We had lot of in-house talent, developers and a legacy system that we just did tons of updates for Y2K. The management started considering many options of having the suppliers send us flat files that we can upload to legacy system, use middleware software that will integrate discrete supplier systems. Like in manufacturing after trying many things we had to go back to the drawing board to see what we were trying to achieve. Hence we had to get a business analyst to draw-up a business requirement to design the system that will solve our problem.

In the next Blog we will look in-depth on what is needed in engineering and in software requirements gathering.

References:
• Kalpakjian, Serope; Steven Schmid (2005). Manufacturing, Engineering & Technology. Prentice Hall, pp. 22-36, 951-988. ISBN 0-1314-8965-8.
• Pyzdek, T, “Quality Engineering Handbook”, 2003, ISBN 0824746147
• Good Automated Manufacturing Practice (GAMP)
• Function Point Analysis: Measurement Practices for Successful Software Projects (Addison-Wesley Information Technology Series) by David Garmus (Author), David Herron (Author)
• Software Engineering (6th Edition) (International Computer Science Series) by Ian Sommerville (Author)