I’ve been thinking a lot about the future of Engineer to Order (ETO) software. We’ve explored the power of Engineer-to-Order processes to acclerate lead times, and the importance of capturing the "WHY" behind ETO. But I find myself asking: What are engineers using today? What could help in the future? I’ve asked my colleague, Kijin Jung, for a glimpse of what the future of ETO software might look like.
In the rush to automate something that’s tedious and routine, the first tool that I turn to is Microsoft Excel. Why? Because I’ve used it for over 25 years. I know it inside and out, effortlessly writing complex formulae with the built in functions, and fluently composing pages of macros. There may be other means to perform the same tasks – like a programming language such as Visual Basic or C++ – but for sheer speed in productivity, I use Excel.
But these are for fairly mundane, repetitive tasks that are relatively minor in scope. What of the engineer working at an Engineer-to-Order (ETO) manufacturer who would like to automate some or all of their design? More often than not, their initial attempts involve Excel as well because of their familiarity with it. One company I had worked with entered over 70,000 lines of Excel macro code to automate a very complex ETO product, constructing a one-of-a-kind design in a quotation (complete with a diagram) that could be sent to their customer, while generating the numbers that could, in the future, be passed manually to their CAD system should the quote become an order.
The wisdom in selecting the right tool for the job at hand becomes immediately apparent. You want something that’s scalable to include new parts and new product lines. You want something that’s shareable with others, not only in your department, but across the entire organization. You want something that’s secure, so that your company’s intellectual property doesn’t walk out the door on a USB drive. Most importantly, you want something that’s maintainable so that others can contribute to the application. A spreadsheet may not be the best hammer.
Turn Back Time… To the Good Old Days
In the early days, we programmers had to write everything in a language in either Emacs or Vi (and that’s the way it was and we liked it!). Integrated development environments (IDEs) were introduced to take care of build automation and provided debugging tools to help find problems in our code. As time passed, more and more environments were created to shield a less tech-savvy person from having to worry about the actual programming itself. One could argue that Excel is a culmination of this evolution.
In the ETO software world, early iterations used programming languages like LISP or FORTRAN. Libraries were provided to generate geometric primitives. While a light user interface surrounded the code editor, make no mistake – you were a LISP or FORTRAN programmer.
Rulestream today provides an easy-to-use point-and-click interface for capturing rules and writing formulae in VB.NET. It’s not quite a no-code ETO software platform where the author is not required to know any programming, but rather a low-code one in which some knowledge of the syntax is helpful. However, Rulestream is flexible enough to allow the author to tailor the system to his liking by allowing the creation of custom functions and providing ways to integrate with other systems that are not supported out-of-the-box.
Instead of requiring the user to deal with class, project, and solution files, the Rulestream Architect client simply offers a way for a subject-matter expert to enter fill-in-the-blank forms to capture knowledge. In addition, the “plumbing” and the connection to databases are taken care of so the author doesn’t have to worry about those aspects of building an ETO software application. With its ability to document the author’s intent, capture knowledge sources, and store the rule history, it delivers a strong, maintainable platform for building ETO products.
On the Horizon
Could we improve Rulestream’s authoring experience? Of course. The concepts that I discuss here are not intended to be a roadmap for Rulestream, but rather one man’s vision of the future.
Think of some of the web development tools such as Wix and Weebly that shield you from HTML, or Android point-and-click development platforms such as MIT App Inventor and Andromo. The biggest advantage of these systems are speed and simplicity, which inherently introduces compromise; if you want to do anything substantial or complex, you may need to look elsewhere. But I think it’s a good starting point for a discussion about user experience.
Many of these tools provide pre-built templates for a variety of layouts and industries, which can be used as a starting point for your own design. Users can drag-and-drop highly intelligent objects that not only represent components of the interface or site, but also embody the syntax of the code itself. As plug-ins and widgets, third-party applications can be added effortlessly with a point-and-click. Development occurs not in a rich-client but on the web, with the ability to build your final application and view your results rapidly.
The Holy Grail of ETO software is to balance an intuitive interface with the need to create highly complex products. Graphical programming will only take you so far; I think the option to go into “advanced mode” will always be essential, but that does not necessarily preclude a comfortable user experience. Imagine being able to automate the design of a unique product that has never been built before, using a combination of standard parts and new parts, capturing hundreds of engineering and business rules encompassing part selection, manufacturability, and pricing – all using a simple, intuitive interface. It may take some time to get there, but I think the future is bright.
About the Author Kijin Jung is a product manager for the Rulestream ETO product at Siemens PLM Software and has spent the past 12 years focused on automation solutions for custom product manufacturers.