Turning Code Into Products On Shelves – Meet the Developer

Munish came to PLM almost by accident: “After doing my masters, I started working for a product-based company selling PLM systems. It was interesting to see how it affects processes and data around various industries.” Over time, he caught the bug, saying “I now see myself buying brands I’ve worked for. Cheese, yoghurt, simple things you buy in the supermarket. It’s amazing.” Having been in the industry for so many years, Munish offers a unique insight into the technical workings behind those simple UIs we know and love.

Background of a developer

Munish describes the most important parts of his job as, “suggesting best possible solution architecture and usage of best practices. Helping customers be up and ready with viewable PLM content. He came to his PLM authority honestly, having worked in a number of different IT roles over his career. He says, “I started out with Java and J2EE, ending up specializing in PLM. Along the way, I’ve worked in different roles as developer, technical lead, solution architect, DevOps.” “I’ve worked with customers across various industries, including Engineering, Hi-Tech, Self-Service, Apparel, Retail and lately on a large customer within the Consumer Packaged Goods (CPG) industry.” “I love to develop new skills, learn new things and solve customer problems. I’m happy to be a part of TECHNIA, which enables me to do that.”

Seeing the fruit of your labour

Why might a developer find PLM so interesting? Perhaps it’s having a tangible result – something you can see. As Munish says, “it’s always amazing to see a product in a shop and relate your part in its PLM journey.” And that journey is often long and winding: “PLM gives us a path to manage the lifecycle of a product from its concept, design, manufacturing, service and usage. It provides a platform for integrating processes, data and people into a single source of truth. It’s the backbone for maintaining information around products. And it helps companies to grow.”

Problem solving

Munish sees PLM implementations as problem solving. And that’s as much about making the software usable, as it is putting the architecture in place. He says, “PLM processes are quite new to the CPG industry and many users are still adapting to this new way of working. Bringing their processes and data onto the PLM platform is a big challenge in itself.” “Providing the right UI, with the right processes – at the same time as maintaining integrations to/from the system – is something we’ve been solving for a while.”

Breaking it down

It’s a big job, best approached a piece at a time. Munish says, “divide it into chunks, prioritize and try to get as much information as possible on every potential scenario and user need. Involve collaboration, tools – get people to discuss and talk.” “We usually do small proof of concepts around CPG requirements, which helps give the business a clear view of the end result. It also helps to bring the right questions to the table so we can develop accurate solutions. We roll it out to production sites in chunks, rather than do Big Bang releases.” The ‘chunk’ philosophy also applies to making the system manageable for users. Munish says, “one example is to configure the system searches so that users can filter ingredients, recipes, semi-finished goods or consumer units based on the sites that produce them. It could also be based on Sourcing Groups/Product Categories, Applicable Claims, Allergens. This gives the user a bird’s eye view, and saves a lot of time trying to find what they’re looking for.”

Building of the future

Even with Munish’s extensive experience, there’s always room for new technology, and new ways of doing things. As he says, “times are changing. There are always new things to learn, new technologies, new processes, new languages; and you need to keep yourself updated to keep up. Luckily, it’s the opportunity to learn new things and develop new skills that keeps me going in IT.” The lessons from Munish’s work behind the scenes could just as easily be applied in front of the curtain, for users of the systems he implements. Break problems down into manageable chunks. And always keep learning. There’s always more to know.