Setup and maintain design files assembly documentation and record production activity on a modern transparent platform.
Shortly after I made the career upgrade to Sail Designer in Sept of 2012, I found the current process to get a design into production needed to be improved. It largely consisted of ill-maintained Word and Excel documents that did not adhere to a consistent format, as well as hand-written details in staff handbooks. It was very time consuming to answer what should have been very simple questions. They were following the “if it’s not broken, then don’t fix it” model, but in order to be more efficient, I knew we needed a change.
I began to write an ASP Classic web front end with an MS Access database backend- while it’s certainly not the ideal choice in today’s rich and powerful ORM / MVC environment, I had no idea it would evolve into the wide reaching production and data analysis tool that it did.
Initial implementation was very simple- store design file names, cloth and usage, per design for each type of yacht. In order not to disrupt the current process, the data was printed out in a similar fashion for production purposes as it had in the past. As more and more classes and designs were available in the database, a newly hired production manager asked me about the possibilities of expanding the database to encompass cloth inventory tracking as well as the “cut log” (a hand written log of sails that were cut on a given day, and what cloth roll identification was used). This was a no-brainer, so I agreed and after a few late nights at home, I had the new features working and gave instructions to plotter operator on how to use the cloth inventory and cut log interfaces. Because the individual design information included the required cloth styles and lengths, it made it really easy to reduce the inventory of a given style by that amount. In the span of a few weeks we greatly increased our visibility of our inventory and what orders were cut from a given roll of cloth, and reduced the staff’s time overhead of writing out similar values over and over. As time went on, the staff became more comfortable asking me to add features as they understood how much easier I could make their daily tasks for them.
Over the course of 5 years the database featureset grew to the point where it was essentially running the San Diego internal production process, and it’s analysis tools allowed management to make big picture decisions based on tangible data rather than generalized assumptions.
Having access to real time information at the click of a button was an absolute game changer. Simple questions like “how many designs use _this_ style of cloth” were easily answered, where as before it would have required a search by hand through a milk crate of analog cut sheets.