I’ll talk about one of the philosophies that I've been using for a while in the implementation of automation tools.

What is Lean Manufacturing?

According to Wikipedia 

“Lean manufacturing is a generic process management philosophy focused on reducing the seven wastes –overproduction, waiting, transportation, over processing, inventory, motion and defects– in manufactured products.

By eliminating waste, not only is quality improved, but also production time and cost are reduced. The “lean” tools include continuous processes of analysis (kaizen), pull production (in the sense of kanban) and error-proofing elements and processes (poka yoke)."

The main principles of Lean Manufacturing are as follows:

• Perfect first-time quality
• Waste minimization
• Continuous improvement
• Pull processing
• Flexibility
• Building and maintaining long term relationships

On the Internet you can find a wealth of material about the subject, so I won’t bore you by making the article longer.

How is it related to Software Engineering?

Even if its origins are in industrial engineering, its philosophy and concepts can be applied to all branches of engineering.
Today, clients demand more flexibility for their products; they want smaller, more frequent deliveries and, of course, they want all delivered products to be of greater quality at a much lower cost.

Therefore, if clients demand more of us, we'll have to do much more to keep them satisfied, as every need will somehow affect each part of the manufacturing process (up to delivery, installation and maintenance of the product).

Only one factor can make a difference, and this factor can make a company succeed (or fail?).

With the purpose of satisfying “clients”, software manufacturers are expanding their reach and focusing –among many other things– on trying to apply the philosophy of Lean Manufacturing. Their goal is to encompass as many processes as possible in order to contribute to the improvement of quality and increase of profits.

My experience

I work for a company whose main product, a Banking Core (Bantotal), is put to the test every day with new requirements and features, some of which are highly specialized, such as Microfinance. I’ve been applying this philosophy in my area for quite some time, both in the development of automation tools and in the processes that support them.

Currently, these tools are playing a key role in the daily production process, giving proof that this philosophy, when correctly applied, works quite well.
Now we’ve taken a path towards everything related to Release Management, leaving small problems aside and starting to seek solutions for more complex problems that should be solved in the future. Many of these problems are related to requirements, regulations and laws imposed on the market, such as regulation 4609 of the BCRA (Argentina), the Sarbanes-Oxley Act (SOX), and Basilea II / III.

Who are my clients? What does the company need?

My job is to implement tools (used both internally and externally), so “my clients” are extremely varied.
Currently I’m working on several projects simultaneously, and they are all related to various stages of the software development process using GeneXus.

The project receiving the most attention right now is called Quirón, and is in charge of automating the “Release” process of the company’s work products. The objective of the project is to succeed in delivering a final product with "perfect first-time quality", seeking to minimize “waste” and “rework”.

In this scenario, we discussed this need with the company, the problems were examined and a conclusion was reached: the quality of the final product cannot be improved just by improving the last link of the production chain. Improvements had to be implemented in earlier stages, incorporating quality and automation in every step of the work process. Thus, in order to achieve this objective, we searched for and found the breakpoint where we had to start working to succeed in creating a five-star final product.

Automation in daily processes

Lately, the star client has been the sector in charge of integration, building and distribution of work products (development and maintenance). Internally, it is called “The sources and shipments sector”. In this scenario, the key principles were applied and tools were developed that assist the sector in performing its daily processes. Our purpose was to introduce, in the shortest time and in the best way possible, the largest number of automatic tasks to guarantee the quality of the entire process.

I want to make clear that this type of project cannot be achieved without people.
Now, the staff has stopped looking at the tree in order to start seeing the wood. Why do I mention precisely this? Because many people associate automation and elimination of unnecessary tasks with layoffs and elimination of jobs.
However, that's not true; what really happens is that people stop doing exhausting, repetitive tasks and start focusing on more complex problems, doing tasks with higher levels of complexity, and providing solutions to these complex problems, which is in line with the philosophy of Lean Manufacturing.

Even though it's rather early to measure results and we have only worked on a few links (we still have to reach the end of the production chain: my clients' client), I wanted to introduce you to this philosophy in the process of production line automation.

Later on I’ll tell you about the complete process, and its relation to Lean Manufacturing and other practices and philosophies, such as Poka Yoke and Jidoka. Of course, I'll also post some updates about the experience obtained along the way.

Lastly, I leave you with a question: has anyone in the Community experimented with automation in the production line?

*Published by David Giordano on Moving Forward, Opening New Doors