About this time, eFlex got a big contract from Navistar to install the eFlex application in a new assembly line at a plant in Springfield, OH that Navistar was currently integrating to build utility vans for GM. The eFlex System driving this assembly line from a frame placed on the line to driving-out-the-door operation. The big challenge here was eFlex’s app had always been model-based, that is, basic manufacturing assembly—engines, transmissions. Not a lot variance. Just model variances. However, what Navistar needed was a component-based system—with LOTS of variances—model, engine, color, tires, wheels, upholstery, entertainment system, and countless options. That was more than a bit tricky. This began in late September. They wanted things to start rolling in February. We had four developers, a couple of project managers, the stakeholders and one designer, me. Off to the races.
I had a lot of configuration and process flow considerations,while at the same time learning all the intricacies of lean manufacturing, the intents of the eFlex application, where the app is now deviating, while brainstorming with the team to the steps forward. BUT, if we got this right, this opened up eFlex Systems to all kinds of potential customers. Imagine! Imagine receiving a numerical string from GM. This string represents everything for a particular build. For an individual vehicle. An abbreviated Bill Of Materials (BOM), so to speak. The eFlex application takes this string, received directly from GM’s enterprise resource planning (ERP) system, translates it to then instruct each station along the line what its tasks are for each different vehicle. eFlex then error-proofs the tasks were done correctly, collects, stores and distributes process data, then moves the part to the next appropriate station. Now, multiply that by several hundred a shift. Did I mention this had to be easy to configure too? So, how do we make this easily configurable? What are the process flows? There are a gazillion moving parts to consider and juggle here! Lucky I work with some people who know their manufacturing grits. After lots of going back and forth we worked out a relatively easy way to manage the complexity of this task, including the ability to manipulate the build information once in the system—adding, editing, and deleting components separate from the BOM. Long story short, several new devs got hired, some on-site, some remote. Though we hired some great talent, the challenge here was quickly and efficiently onboarding the new devs without losing the efficiency of the veteran developers. This is a very complex application to begin with, the project added much more complexity and challenges. Lots of moving parts. Onboarding landed primarily on the current, already strapped developers to bring on the new devs. They worked weekends for four months. The job successfully got done. A big hit at Navistar—a record to implement an entire new assembly line so quickly. And new ground for eFlex Systems! An honor for me to be part of such a talented group.
I mentioned we were getting the build information from GM’s ERP system via an integration layer called GEPICS through SOAP. We created an interface for engineers that was comprehensive for all that was needed to accomplish this transfer—but still may have been overwhelming for some folks—especially the Complex Options Builder (COB). In a nutshell, COB is an If This Then That (ITTT) type of operation, kinda. If, for example, a common build called for a common side mirror, however, IF the vehicle also had, say, a certain luggage carrier on the roof, THEN THAT would need a certain mounting bracket added to the build. These types of edge cases had to have a mechanism to handle it. Thus the Complex Options Builder. Or, another example as shown below, building a complex component based on AND. That is common components combined together to create the complex component—if the BOM calls for a tire which is a mud tire, AND is a mud tire with black heavy-duty mud flap AND is on flared wheel wells without the gray light duty mudlaps. This then can be used again as an existing component—or combined yet with another. Illustrated below is the Component/Options tab which fills from the BOM. The left panel lists all the components. Select a component and the right panel lists all that component's options and any complex options—designated with the EDIT button. Clicking the ADD COMPLEX OPTION footer button launches a modal with the Complex Options Builder described above. GM and Navistar used one kind scheduling source (GEIPICS) to deliver their BOMs to us. Faurecia immediately wanted to implement this system to a new line they were integrating in Fraser, MI to build center-stack modules for some Ford SUVs. They used a different scheduling source to deliver to us. Insequence. Likely, other users yet will use yet other delivery methods. So there has to be a simple method to accommodate numerous unknowns. Back to the drawing board.
On a hunch, the VP of Engineering had me mockup a process and a prototype for a wizard-type of configuration for the initial set-up. He felt this was a complex page and would only be used annually, thus the user easily forgetting what has to be done. It made sense and I’ve always been a huge fan of breaking down complexity into smaller chunks. We never really did any user-testing to determine preference of one complex page or wizard, but the wizard stuck and got implemented along with the one complex, Build File Information configuration screen page, shown above. The Engineering VP caught some shareholder flack for the time, effort, and expense into developing the wizard when there was already [the complex] build file information page. I personally feels it serves a good purpose and would like to see more such wizards implemented and offered on more such complex configurations. For power users or those it's simply understood, then yeah, direct input onto the Build File Information screen is a great option. There were tons of other Navistar requirements that required research, collaboration, user-centric process design, configurations, and UI considerations: a REST adapter, Footprint and Sequence configuration and color scheming, PLC integration, a component-based Part Build Report, a Repair screen, a Serial Number Monitor and more. All intricate case studies on their own. In the end, Navistar was very happy. GM was impressed. Soon after a group of engineers from another GM plant eFlex serviced was in the office to see a demo. A lot of smiles, a lot of head nodding, and a lot of hi-5s. This opened up eFlex’s prospects in a wide-ranging way—to virtually any kind of manufacturing. This tickled the Sales team for it opened so many more doors for them. We were even getting non-manufacturing inquiries—for our process control capabilities. The Veterans Administration, who doesn’t manufacture, but they do robotic surgeries that then require precise recalibration and sterilizations approached eFlex to enforce processes and call error on improper procedure. There was also a prospect looking to instill maintenance centers around the world, using our system to implement a Primary/Replica solution to configure in one Primary location (e.g. San Francisco) and shoot out to all the Replica locations (e.g. L.A., Denver, Austin, St Louis, Chicago, Detroit, NY… London, Paris, Rome…). More on this later. What this tech now allows is Lean Manufacturing On-Demand. That is, a customer can now efficiently order a product customized to their preferences. "Efficiently" by the click of a button and with blockchain technology, an order can automatically be created, financing established, factory order submitted, smart contracts pay an initial installment, which generates orders and payments through the entire supply chain. Upon delivery, the remainder of the payments are released.