# 8 - Technology Development

The development of a Technology Roadmap is a necessity for an Engineering organization that seeks to get ahead in the development curve such that the technology developments are readily prepared when the need for inclusion in the Product Development has arrived. 


First and foremost, in order to begin a Technology Roadmap, an appropriate team must be formed from within the organization. This team should represent a cross section of the major functions of the organization, and in a typical manufacturing company would include members from the Operations group, Manufacturing personnel, Engineering, Sales personnel, Marketing and Services to name a few. These members are selected largely as representatives of their functional areas within the development in order to ensure all facets of the potential product and technologies are considered with regard to the constraints and limitations of the organization.

The next major hurdle in the development of the Roadmap is to effectively define the constraints of the problem or challenge faced by the organization. To accomplish this, we need to examine the current status of the organization in detail and produce a coherent understanding of the customer base and products. Beware of the famous "We will figure out later" when it comes to a key aspect of futur development. It's obviously the easy way out, but it's also the main reason why Technology Development efforts fail! Even if it's not always easy, we must put the extra effort at the beginning of the development to reduce the risk on future development. A lot of tools and methods are widely available and can really help managing the early stages of Technology Development (e.g, Systems Engineering approach)

A typical approach must consider the hierarchy of technology development. This includes a five-stage process:
- Concept Refinement stage (Technology Readiness Level (TRL) 1 to 2): Development of new concepts
- Technology Development stage (TRL 3 to 4): Establish if the conceptualized system will function effectively
- System Development and Demonstration stage (TRL 5 to 6): Complete the technology development and prototype, ultimately getting the system to release.
- Production and Development stage (TRL 7 to 8): Small lot production and refinement.
- Operations and Support stage (TRL 8 to 9): Logistics and sustainment for products.

How to do Technology Assessment

The technology assessment process typically makes use of basic systems engineering principles and processes. It is a two step process comprised of (1) the determination of the current technological maturity in terms of TRLs and (2) the determination of the difficulty associated with moving a technology from one TRL to the next.



A Technology Readiness Level (TRL) is, at its most basic, a description of the performance history of a given system, subsystem or component relative to a set of levels. The TRL essentially describes the state of a given technology and provides a baseline from which maturity is gauged and advancement defined. Programs are often undertaken without fully understanding either the maturity of key technologies or what is needed to develop them to the required level. It is impossible to understand the magnitude and scope of a development program without having a clear understanding of the baseline technological maturity of all elements of the system. Establishing the TRL is a vital first step on the way to a successful program. A frequent misconception is that in practice, it is too difficult to determine TRLs and that when you do, it is not meaningful. On the contrary, identifying TRLs can be a straightforward systems engineering process of determining what was demonstrated and under what conditions it was demonstrated.program. A frequent misconception is that in practice, it is too difficult to determine TRLs and that when you do, it is not meaningful. On the contrary, identifying TRLs can be a straightforward systems engineering process of determining what was demonstrated and under what conditions it was demonstrated.
       

Comments

Post a Comment

Popular posts from this blog

# 11 - Model-Based Systems Engineering (MBSE)

The best way to understand the MBSE approach is to begin by understanding the alternative: what modeling partitioners call the document-based approach to engineering (and what nonpractitioners call "the way we have always done things!"). With the document-based approach, engineers manually generate some subset of the following artifacts: concept of operations (ConOps) documents, requirements specifications, requirements traceability and verification matrices, interface definition documents, systems design specifications and speciality engineering analysis such as analyses of reliability, FMEA, etc. Document-based systems engineers produce these artifacts in a form of a disjoint set of text documents, spreadsheet, diagrams, presentations (and configuration-manage them in a disjoint set of repositories). The document-based approach is expensive. More precisely, it's more expensive than it needs to be; you incur a significant percentage of total life cycle cost maintaining t...
Read more

# 10 - Principles of Dynamic Work Design

Image
Consider a well-known example of work and organizational design, Toyota’s Andon cord. In the Toyota scheme, a worker noticing such an issue is supposed to pull what’s known as the Andon cord (or push a button) to stop the production line and fix the problem. While the management literature has correctly highlighted the importance of allowing employees to stop the line, what happens after the cord is pulled might be more important. When one operator on the factory floor is struggling to complete a task in the allotted time, and so hit a yellow button, causing an alarm to sound and a light to flash. Within seconds, the line’s supervisor arrived and assisted the operator in resolving the issue that was preventing him from following the prescribed process. In less than a minute, the operator, now able to hit his target, returned to his normal routine, and the supervisor went back to other activities. A visual of this process can be seen below: What, from a work design perspective, happened...
Read more

# 12 - MOEs, MOPs and TPMs

Let's start by defining these acronyms: - MOEs: Measures Of Effectiveness - MOPs: Measures Of Performance - TPMs: Technical Performance Mesures Following a recent discussion on this topic, I've come to realize that there is a lot of confusion around these concepts, so let's try to bring some clarification! MOEs, which are stated from the acquirer (customer/user) viewpoint, are the acquirer's key indicators of achiving the needs for performance, suitability and affordability across the life cycle. The MOEs are used to validate the system at each stage of the design process and provide insight into some of the more subjective qualities desired by the acquirer that are not, or can not, be captured by hard requirements. Many of the "ilities" are used in MOEs where, for example, it may be very difficult to generate a shall statement on operability, but operability nevertheless remains an important characteristic. MOPs measure attributes considered as important to e...
Read more