Tag: manufacturing

Process Management (Project Management)

Process management in civil engineering and project management is the management of “systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs.”

Process management offers project organizations a means of applying the same quality improvement and defect reduction techniques used in business and manufacturing processes by taking a process view of project activity; modeling discrete activities and high-level processes.

The term process management usually refers to the management of engineering processes and project management processes where a process is a collection of related, structured tasks that produce a specific service or product to address a certain goal for a particular actor or set of actors.

Processes can be executed with procedures. They can be described as a sequence of steps that can execute a process and their value lies in that they are an accepted method of accomplishing a consistent performance or results.

Process management provides engineering and project managers with a means of systemically thinking of project organizations, Semantics concepts and logical frameworks that allow project activities to be planned, executed, analyzed and facilitate learning.

In order for process management as defined to deliver consistent performance, it requires definition, elimination of non-Value added activities, continuous improvement, project stakeholder focus and team based approach. Mitchell (2016) notes that managing processes across divisional and organizational boundaries requires a more flexible management strategy as well as close cooperation among managers in diverse functional and operational units to ensure that the process flow is not interrupted by conflicts over lines of authority.

Process management originated as part of the manufacturing-based application of statistical quality control movement in the late 1920s and early 1930s. What is relatively new, however, is the transition of process management methods from a manufacturing environment to a total company orientation and project management.

Process management in the context of project management or engineering represents a change from the traditional concept of organizational authority using hierarchies and organizational structure to one requiring flexibility to ensure efficient process workflows. Mitchell (2016) notes that managing processes across divisional and organizational boundaries requires a more flexible management strategy as well as close cooperation among managers in diverse functional and operational units to ensure that the process flow is not interrupted by conflicts over lines of authority.

Cooper, et. al. note that manufacturing has been “a constant reference point and a source of innovation in construction”. There is a new phenomenon occurring within the construction sector that is based upon the development and use of fundamental core management processes to improve the efficiency of the industry.

In the field of process management the notion of process, according to Mitchell (2016), can be characterized by:

These concepts provides management with the following:

Process management in this context requires engineering knowledge, management activities and skill sets whereas business processes or manufacturing processes require operations management activities, and skill sets.

Process models are `an effective way to show how a process works’. Project Management process modeling tools provide managers and engineering professionals with the ability to model their processes, implement and execute those models, and refine the models based on actual performance. The result is that business process modeling tools can provide transparency into project management processes, as well as the centralization of project organization process models and execution metrics.
A number of modelling/systems analysis techniques exist such as data flow diagrams (DFD), HIPO model (hierarchy + input-process-output), data modeling and IDEF0 (integration definition language 0 for function modelling) process modelling technique.

A process activity that is concurrent or simultaneously executing can be termed a thread.

ISO 9000 promotes the process approach to managing an organization.

…promotes the adoption of a process approach when developing, implementing and improving the effectiveness of a quality management system, to enhance customer satisfaction by meeting customer requirements.

Get More PRINCE2 Information by Clicking HERE

Kanban

Prince2 Certification
Image by/from

Karen Abeyasekere, U.S. Air Force

 

Kanban (看板) (signboard or billboard in Japanese) is a scheduling system for lean manufacturing and just-in-time manufacturing (JIT). Taiichi Ohno, an industrial engineer at Toyota, developed kanban to improve manufacturing efficiency. Kanban is one method to achieve JIT. The system takes its name from the cards that track production within a factory. For many in the automotive sector, kanban is known as the “Toyota nameplate system” and as such the term is not used by some other automakers.[clarification needed]

Kanban became an effective tool to support running a production system as a whole, and an excellent way to promote improvement. Problem areas are highlighted by measuring lead time and cycle time of the full process and process steps.[clarification needed] One of the main benefits of kanban is to establish an upper limit to work in process inventory to avoid overcapacity. Other systems with similar effect exist, for example CONWIP. A systematic study of various configurations of kanban systems, of which CONWIP is an important special case, can be found in Tayur (1993), among other papers.

A goal of the kanban system is to limit the buildup of excess inventory at any point in production. Limits on the number of items waiting at supply points are established and then reduced as inefficiencies are identified and removed. Whenever a limit is exceeded, this points to an inefficiency that should be addressed.

The system originates from the simplest visual stock replenishment signaling system, an empty box. This was first developed in the UK factories producing Spitfires during the Second World War, and was known as the “two bin system.” In the late 1940s, Toyota started studying supermarkets with the idea of applying shelf-stocking techniques to the factory floor. In a supermarket, customers generally retrieve what they need at the required time—no more, no less. Furthermore, the supermarket stocks only what it expects to sell in a given time, and customers take only what they need, because future supply is assured. This observation led Toyota to view a process as being a customer of one or more preceding processes and to view the preceding processes as a kind of store.

Kanban aligns inventory levels with actual consumption. A signal tells a supplier to produce and deliver a new shipment when a material is consumed. This signal is tracked through the replenishment cycle, bringing visibility to the supplier, consumer, and buyer.

Kanban uses the rate of demand to control the rate of production, passing demand from the end customer up through the chain of customer-store processes. In 1953, Toyota applied this logic in their main plant machine shop.

A key indicator of the success of production scheduling based on demand, pushing, is the ability of the demand-forecast to create such a push. Kanban, by contrast, is part of an approach where the pull comes from demand and products are made to order. Re-supply or production is determined according to customer orders.

In contexts where supply time is lengthy and demand is difficult to forecast, often the best one can do is to respond quickly to observed demand. This situation is exactly what a kanban system accomplishes, in that it is used as a demand signal that immediately travels through the supply chain. This ensures that intermediate stock held in the supply chain are better managed, and are usually smaller. Where the supply response is not quick enough to meet actual demand fluctuations, thereby causing potential lost sales, a stock building may be deemed more appropriate and is achieved by placing more kanban in the system.

Taiichi Ohno stated that to be effective, kanban must follow strict rules of use. Toyota, for example, has six simple rules, and close monitoring of these rules is a never-ending task, thereby ensuring that the kanban does what is required.

Toyota has formulated six rules for the application of kanban:

Kanban cards are a key component of kanban and they signal the need to move materials within a production facility or to move materials from an outside supplier into the production facility. The kanban card is, in effect, a message that signals a depletion of product, parts, or inventory. When received, the kanban triggers replenishment of that product, part, or inventory. Consumption, therefore, drives demand for more production, and the kanban card signals demand for more product—so kanban cards help create a demand-driven system.

It is widely held by proponents of lean production and manufacturing that demand-driven systems lead to faster turnarounds in production and lower inventory levels, helping companies implementing such systems be more competitive.

In the last few years, systems sending kanban signals electronically have become more widespread. While this trend is leading to a reduction in the use of kanban cards in aggregate, it is still common in modern lean production facilities to find the use of kanban cards. In various software systems, kanban is used for signalling demand to suppliers through email notifications. When stock of a particular component is depleted by the quantity assigned on kanban card, a “kanban trigger” is created (which may be manual or automatic), a purchase order is released with predefined quantity for the supplier defined on the card, and the supplier is expected to dispatch material within a specified lead-time.

Kanban cards, in keeping with the principles of kanban, simply convey the need for more materials. A red card lying in an empty parts cart conveys that more parts are needed.

An example of a simple kanban system implementation is a “three-bin system” for the supplied parts, where there is no in-house manufacturing. One bin is on the factory floor (the initial demand point), one bin is in the factory store (the inventory control point), and one bin is at the supplier. The bins usually have a removable card containing the product details and other relevant information, the classic kanban card.

When the bin on the factory floor is empty (because the parts in it were used up in a manufacturing process), the empty bin and its kanban card are returned to the factory store (the inventory control point). The factory store replaces the empty bin on the factory floor with the full bin from the factory store, which also contains a kanban card. The factory store sends the empty bin with its kanban card to the supplier. The supplier’s full product bin, with its kanban card, is delivered to the factory store; the supplier keeps the empty bin. This is the final step in the process. Thus, the process never runs out of product—and could be described as a closed loop, in that it provides the exact amount required, with only one spare bin so there is never oversupply. This ‘spare’ bin allows for uncertainties in supply, use, and transport in the inventory system. A good kanban system calculates just enough kanban cards for each product. Most factories that use kanban use the colored board system (heijunka box).

Many manufacturers have implemented electronic kanban (sometimes referred to as e-kanban) systems. These help to eliminate common problems such as manual entry errors and lost cards. E-kanban systems can be integrated into enterprise resource planning (ERP) systems, enabling real-time demand signaling across the supply chain and improved visibility. Data pulled from E-kanban systems can be used to optimize inventory levels by better tracking supplier lead and replenishment times.

E-kanban is a signaling system that uses a mix of technology to trigger the movement of materials within a manufacturing or production facility. Electronic Kanban differs from traditional kanban in using technology to replace traditional elements like kanban cards with barcodes and electronic messages like email or Electronic data interchange.

A typical electronic kanban system marks inventory with barcodes, which workers scan at various stages of the manufacturing process to signal usage. The scans relay messages to internal/external stores to ensure the restocking of products. Electronic kanban often uses the internet as a method of routing messages to external suppliers and as a means to allow a real-time view of inventory, via a portal, throughout the supply chain.

Organizations like the Ford Motor Company and Bombardier Aerospace have used electronic kanban systems to improve processes. Systems are now widespread from single solutions or bolt on modules to ERP systems.

In a kanban system, adjacent upstream and downstream workstations communicate with each other through their cards, where each container has a kanban associated with it. Economic Order Quantity is important. The
two most important types of kanbans are:

The Kanban philosophy and Task Boards are also used in Agile project management to coordinate tasks in project teams. An online demonstration can be seen in an Agile Simulator.

Get More PRINCE2 Information by Clicking HERE

Project Engineering

Project engineering includes all parts of the design of manufacturing or processing facilities, either new or modifications to and expansions of existing facilities. A “project” consists of a coordinated series of activities or tasks performed by engineers, designers, drafters and others from one or more engineering disciplines or departments. Project tasks consist of such things as performing calculations, writing specifications, preparing bids, reviewing equipment proposals and evaluating or selecting equipment and preparing various lists, such as equipment and materials lists, and creating drawings such as electrical, piping and instrumentation diagrams, physical layouts and other drawings used in design and construction. A small project may be under the direction of a project engineer. Large projects are typically under the direction of a project manager or management team. Some facilities have in house staff to handle small projects, while some major companies have a department that does internal project engineering. Large projects are typically contracted out to engineering companies. Staffing at engineering companies varies according to the work load and duration of employment may only last until an individual’s tasks are completed.

The role of the project engineer can often be described as that of a liaison between the project manager and the technical disciplines involved in a project. The distribution of “liaising” and performing tasks within the technical disciplines can vary wildly from project to project; this often depends on the type of product, its maturity, and the size of the company, to name a few. It is important for a project engineer to understand that balance. The project engineer should be knowledgeable enough to be able to speak intelligently within the various disciplines, and not purely be a liaison. The project engineer is also often the primary technical point of contact for the consumer.

A project engineer’s responsibilities include schedule preparation, pre-planning and resource forecasting for engineering and other technical activities relating to the project. They may also be in charge of performance management of vendors. They assure the accuracy of financial forecasts, which tie-in to project schedules. They ensure projects are completed according to project plans. Project engineers manage project team resources and training and develop extensive project management experience and expertise.

When use, an engineering company is generally contracted to conduct a study (capital cost estimate or technical assessment) or to design a project. Projects are designed to achieve some specific objective, ranging in scope from simple modifications to new factories or expansions costing hundreds of millions or even billions of dollars. The client usually provides the engineering company with a scoping document listing the details of the objective in terms of such things as production rate and product specifications and general to specific information about processes and equipment to be used and the expected deliverables, such as calculations, drawings, lists, specifications, schedules, etc. The client is typically involved in the entire design process and makes decisions throughout, including the technology, type of equipment to use, bid evaluation and supplier selection, the layout of equipment and operational considerations. Depending on the project the engineering company may perform material and energy balances to size equipment and to quantify inputs of materials and energy (steam, electric power, fuel). This information is used to write specifications for the equipment. The equipment specifications are sent out for bids. The client, the engineering company or both select the equipment. The equipment suppliers provide drawings of the equipment, which are used by the engineering company’s mechanical engineers, and drafters to make general arrangement drawings, which show how the pieces of equipment are located in relation to other equipment. Layout drawings show specific information about the equipment, electric motors powering the equipment and such things as auxiliary equipment (pumps, fans, air compressors), piping and buildings. The engineering company maintains an equipment list with major equipment, auxiliary equipment, motors, etc. Electrical engineers are involved with power supply to motors and equipment. Process engineers perform material and energy balances and design the piping and instrumentation diagrams to show how equipment is supplied with process fluids, water, air, gases, etc. and the type of control loops used. The instrumentation and controls engineers specify the instrumentation and controls and handle any computer controls and control rooms. Civil and structural engineers deal with site layout and engineering, building design and structural concerns like foundations, pads, structures, supports and bracing for equipment. Environmental engineers deal with any air emissions and treatment of liquid effluent.

The various fields and topics that projects engineers are involved with include:

Project engineers are often project managers with qualifications in engineering or construction management. Other titles include field engineer, construction engineer, or construction project engineer. In smaller projects, this person may also be responsible for contracts and will be called an assistant project manager. A similar role is undertaken by a client’s engineer or owner’s engineer, but by inference, these often act more in the interests of the commissioning company.

Project engineers do not necessarily do design work, but instead represent the contractor or client out in the field, help tradespeople interpret the job’s designs, ensure the job is constructed according to the project plans, and assist project controls, including budgeting, scheduling, and planning. In some cases a project engineer is responsible for assisting the assigned project manager with regard to design and a project and with the execution of one or more simultaneous projects in accordance with a valid, executed contract, per company policies and procedures and work instructions for customized and standardized plants.

Typical responsibilities may include: daily operations of field work activities and organization of subcontractors; coordination of the implementation of a project, ensuring it is being built correctly; project schedules and forecasts; interpretation of drawings for tradesmen; review of engineering deliverables; redlining drawings; regular project status reports; budget monitoring and trend tracking; bill of materials creation and maintenance; effective communications between engineering, technical, construction, and project controls groups; and assistance to the project manager.

Get More PRINCE2 Information by Clicking HERE

Design for Six Sigma

Design for Six Sigma (DFSS) is a business process management method related to traditional Six Sigma. It is used in many industries, like finance, marketing, basic engineering, process industries, waste management, and electronics. It is based on the use of statistical tools like linear regression and enables empirical research similar to that performed in other fields, such as social science. While the tools and order used in Six Sigma require a process to be in place and functioning, DFSS has the objective of determining the needs of customers and the business, and driving those needs into the product solution so created. DFSS is relevant for relatively simple items / systems. It is used for product or process design in contrast with process improvement. Measurement is the most important part of most Six Sigma or DFSS tools, but whereas in Six Sigma measurements are made from an existing process, DFSS focuses on gaining a deep insight into customer needs and using these to inform every design decision and trade-off.

There are different options for the implementation of DFSS. Unlike Six Sigma, which is commonly driven via DMAIC (Define – Measure – Analyze – Improve – Control) projects, DFSS has spawned a number of stepwise processes, all in the style of the DMAIC procedure.

DMADV, define – measure – analyze – design – verify, is sometimes synonymously referred to as DFSS, although alternatives such as IDOV (Identify, Design, Optimize, Verify) are also used. The traditional DMAIC Six Sigma process, as it is usually practiced, which is focused on evolutionary and continuous improvement manufacturing or service process development, usually occurs after initial system or product design and development have been largely completed. DMAIC Six Sigma as practiced is usually consumed with solving existing manufacturing or service process problems and removal of the defects and variation associated with defects. It is clear that manufacturing variations may impact product reliability. So, a clear link should exist between reliability engineering and Six Sigma (quality). In contrast, DFSS (or DMADV and IDOV) strives to generate a new process where none existed, or where an existing process is deemed to be inadequate and in need of replacement. DFSS aims to create a process with the end in mind of optimally building the efficiencies of Six Sigma methodology into the process before implementation; traditional Six Sigma seeks for continuous improvement after a process already exists.

DFSS seeks to avoid manufacturing/service process problems by using advanced techniques to avoid process problems at the outset (e.g., fire prevention). When combined, these methods obtain the proper needs of the customer, and derive engineering system parameter requirements that increase product and service effectiveness in the eyes of the customer and all other people. This yields products and services that provide great customer satisfaction and increased market share. These techniques also include tools and processes to predict, model and simulate the product delivery system (the processes/tools, personnel and organization, training, facilities, and logistics to produce the product/service). In this way, DFSS is closely related to operations research (solving the knapsack problem), workflow balancing. DFSS is largely a design activity requiring tools including: quality function deployment (QFD), axiomatic design, TRIZ, Design for X, design of experiments (DOE), Taguchi methods, tolerance design, robustification and Response Surface Methodology for a single or multiple response optimization. While these tools are sometimes used in the classic DMAIC Six Sigma process, they are uniquely used by DFSS to analyze new and unprecedented products and processes. It is a concurrent analyzes directed to manufacturing optimization related to the design.

Response surface methodology and other DFSS tools uses statistical (often empirical) models, and therefore practitioners need to be aware that even the best statistical model is an approximation to reality. In practice, both the models and the parameter values are unknown, and subject to uncertainty on top of ignorance. Of course, an estimated optimum point need not be optimum in reality, because of the errors of the estimates and of the inadequacies of the model.

Nonetheless, response surface methodology has an effective track-record of helping researchers improve products and services: For example, George Box’s original response-surface modeling enabled chemical engineers to improve a process that had been stuck at a saddle-point for years.

Proponents of DMAIC, DDICA (Design Develop Initialize Control and Allocate) and Lean techniques might claim that DFSS falls under the general rubric of Six Sigma or Lean Six Sigma (LSS). Both methodologies focus on meeting customer needs and business priorities as the starting-point for analysis.

It is often seen that[weasel words] the tools used for DFSS techniques vary widely from those used for DMAIC Six Sigma. In particular, DMAIC, DDICA practitioners often use new or existing mechanical drawings and manufacturing process instructions as the originating information to perform their analysis, while DFSS practitioners often use simulations and parametric system design/analysis tools to predict both cost and performance of candidate system architectures. While it can be claimed that[weasel words] two processes are similar, in practice the working medium differs enough so that DFSS requires different tool sets in order to perform its design tasks. DMAIC, IDOV and Six Sigma may still be used during depth-first plunges into the system architecture analysis and for “back end” Six Sigma processes; DFSS provides system design processes used in front-end complex system designs. Back-front systems also are used. This makes 3.4 defects per million design opportunities if done well.

Traditional six sigma methodology, DMAIC, has become a standard process optimization tool for the chemical process industries.
However, it has become clear that[weasel words] the promise of six sigma, specifically, 3.4 defects per million opportunities (DPMO), is simply unachievable after the fact. Consequently, there has been a growing movement to implement six sigma design usually called design for six sigma DFSS and DDICA tools. This methodology begins with defining customer needs and leads to the development of robust processes to deliver those needs.

Design for Six Sigma emerged from the Six Sigma and the Define-Measure-Analyze-Improve-Control (DMAIC) quality methodologies, which were originally developed by Motorola to systematically improve processes by eliminating defects. Unlike its traditional Six Sigma/DMAIC predecessors, which are usually focused on solving existing manufacturing issues (i.e., “fire fighting”), DFSS aims at avoiding manufacturing problems by taking a more proactive approach to problem solving and engaging the company efforts at an early stage to reduce problems that could occur (i.e., “fire prevention”). The primary goal of DFSS is to achieve a significant reduction in the number of nonconforming units and production variation. It starts from an understanding of the customer expectations, needs and Critical to Quality issues (CTQs) before a design can be completed. Typically in a DFSS program, only a small portion of the CTQs are reliability-related (CTR), and therefore, reliability does not get center stage attention in DFSS. DFSS rarely looks at the long-term (after manufacturing) issues that might arise in the product (e.g. complex fatigue issues or electrical wear-out, chemical issues, cascade effects of failures, system level interactions).

Arguments about what makes DFSS different from Six Sigma demonstrate the similarities between DFSS and other established engineering practices such as probabilistic design and design for quality. In general Six Sigma with its DMAIC roadmap focuses on improvement of an existing process or processes. DFSS focuses on the creation of new value with inputs from customers, suppliers and business needs. While traditional Six Sigma may also use those inputs, the focus is again on improvement and not design of some new product or system. It also shows the engineering background of DFSS. However, like other methods developed in engineering, there is no theoretical reason why DFSS cannot be used in areas outside of engineering.

Historically, although the first successful Design for Six Sigma projects in 1989 and 1991 predate establishment of the DMAIC process improvement process, Design for Six Sigma (DFSS) is accepted in part because Six Sigma organisations found that they could not optimise products past three or four Sigma without fundamentally redesigning the product, and because improving a process or product after launch is considered less efficient and effective than designing in quality. ‘Six Sigma’ levels of performance have to be ‘built-in’.

DFSS for software is essentially a non superficial modification of “classical DFSS” since the character and nature of software is different from other fields of engineering. The methodology describes the detailed process for successfully applying DFSS methods and tools throughout the software product design, covering the overall Software Development life cycle: requirements, architecture, design, implementation, integration, optimization, verification and validation (RADIOV). The methodology explains how to build predictive statistical models for software reliability and robustness and shows how simulation and analysis techniques can be combined with structural design and architecture methods to effectively produce software and information systems at Six Sigma levels.

DFSS in software acts as a glue to blend the classical modelling techniques of software engineering such as object-oriented design or Evolutionary Rapid Development with statistical, predictive models and simulation techniques. The methodology provides Software Engineers with practical tools for measuring and predicting the quality attributes of the software product and also enables them to include software in system reliability models.

Although many tools used in DFSS consulting such as response surface methodology, transfer function via linear and non linear modeling, axiomatic design, simulation have their origin in inferential statistics, statistical modeling may overlap with data analytics and mining,

However, despite that DFSS as a methodology has been successfully used as an end-to-end [technical project frameworks ] for analytic and mining projects, this has been observed by domain experts to be somewhat similar to the lines of CRISP-DM

DFSS is claimed to be better suited for encapsulating and effectively handling higher number of uncertainties including missing and uncertain data, both in terms of acuteness of definition and their absolute total numbers with respect to analytic s and data-mining tasks, six sigma approaches to data-mining are popularly known as DFSS over CRISP [ CRISP- DM referring to data-mining application framework methodology of SPSS ]

With DFSS data mining projects have been observed to have considerably shortened development life cycle . This is typically achieved by conducting data analysis to pre-designed template match tests via a techno-functional approach using multilevel quality function deployment on the data-set.

Practitioners claim that progressively complex KDD templates are created by multiple DOE runs on simulated complex multivariate data, then the templates along with logs are extensively documented via a decision tree based algorithm

DFSS uses Quality Function Deployment and SIPOC for feature engineering of known independent variables, thereby aiding in techno-functional computation of derived attributes

Once the predictive model has been computed, DFSS studies can also be used to provide stronger probabilistic estimations of predictive model rank in a real world scenario

DFSS framework has been successfully applied for predictive analytics pertaining to the HR analytics field, This application field has been considered to be traditionally very challenging due to the peculiar complexities of predicting human behavior.