How to escape “listing” paradigm and reinvent ECO

How to escape “listing” paradigm and reinvent ECO

Bound_computer_printout.agr

Do you remember what is “hard copy listing”? If you had a chance to write software programs in 1980s, you might remember “listings” – a printed list of computer code or digital data in a human reading format. Navigate to the following Wikipedia article to refresh your memory. We don’t do listings anymore. It is gone. Wikipedia explains that in a dead simple language:

Today, hard copy listings are seldom used because display screens can present more lines than formerly, programs tend to be modular, storage in soft copy is considered preferable to hard copy, and digital material is easily transmitted via networks, or on disks or tapes. Furthermore, data sets tend to be too large to be conveniently put on paper, and they are more easily searched in soft-copy form.

My long time blogging buddy Ed Lopategui is discussing common practices and challenges manufacturing companies are experiencing with ECO (Engineering Change Management). I recommend you to take a look on the following two articles on GrabCAD blog: ECOs Aren’t Dead, But They Are Slow and Stupid and ECOs are stupid II: The price of unincorporated change. ECO best practices are heavily influenced by traditional approach of paper-oriented world following old-school configuration management standards. The following passage explains it very well:

Most engineering change processes are rooted in very formal and traditional frameworks. ECOs can be traced back to Configuration Management (CM) practices that literally come from a time well before CAD (much less PDM/PLM) where manual drawings ruled the earth. Engineering data was neither readily portable nor widely accessible. These effective but complex practices were established in the larger, older manufacturing companies that became the first natural customers to afford PDM/PLM.. As a result, these processes live on and are perceived as absolutes. They remain relatively intact, buoyed by large company process culture despite the opportunity to evolve.

Unincorporated change is another archaic practice, which is a reflection of old practice of making changes in drawings. The complexity of changing documentation created the practice of change process itself. So called “was-now” practice was related to the fact comparison between two states of the design was very complicated:

The concept of an unincorporated change was a necessary compromise in the past because of limitations in changing design data, especially in the era of manual drawings and early CAD, when drawing views didn’t just update with a click or two. Understanding the difference from one version of a design to another chiefly involved intense staring for prolonged periods of time until the change was understood and/or blindness occurred. To minimize eye strain, ECOs often highlighted the changes specifically, sometimes with designation of WAS/NOW views side by side on the form.

Now, let’s move into modern world of software. Imagine software engineer is writing a paper document with explanation about code changes he is going to implement tomorrow. He prints “listing” and mark by yellow color “was/now” differences in the code. Then apply it for approval and documentation. After it made, actual change is going to be performed. It is probably sounds strange.

The traditional PLM paradigms are very much like old-school software listings. It is slow and complicated. I’m consistently hearing engineers are not making formal changes and not abandoning lifecycle process because to perform lifecycle is slow and complicated. Nobody wants to deal with complicated forms and processes. In many situations the process is just too complex for teams and people to deal with. I pointed some of these problems in my earlier article – why PLM should revise NPI products.

Agile software development became very popular for the last decade. It introduces many concepts that can be adopted by manufacturing companies. One of the most interesting opportunity I can see is around how to make change management fast and easy. When it comes to change, the speed is a very important thing.

What is my conclusion? Old habits die hard. ECO is one of them and it goes back 20-30 years to best practices that were developed before CAD systems were capable to compare two versions of the model and visualize differences. Check my earlier post about how to compare versions and changes. New technologies and new practices should come and displace old “ECO listings” in an agile, paperless and easy way. Just my thoughts…

Best, Oleg

Picture is credit Wikipedia article – Computer Listing.

Share

Share This Post