Hello,
In my case, for a certain planning task SAS/OR seems to compete with SAP because SAS obviously has neat analytical capabilities. SAP on the other hand, is intended for large data volumes and "deals with messy data itself, will always give a result, processing time will be competitive, etc., etc.". The data in question is large - and I even don't yet know how large. Gambling is not my favorite option, if we go for SAS, it shouldn't be a mistake. In spite of being a SAS fan, carrying out a google search on "proc bom" and getting "forecast aggregation" in third and fourth place as most relevant topics really gives me the creeps.
a) How can I tell in advance that my planned bill-of-materials calculation will not break down - due to lack of memory?
b) Has anybody real life experience with proc bom doing bill-of-materials explosion - using it for materials and not forecast aggregation?
Thanks&kind regards
Thanks for your question. A lot of our SAS/OR users aren't particularly vocal about their use of the software because they consider it to be intrinsic to their competitive advantage. Because our software is licensed at the product level, we don't have any systematic way to track who is using individual procedures and how. We have to wait for them to tell us. Sometimes a user encounters a difficulty and contacts SAS Technical Support for help. Sometimes a user contacts me directly with a question or a comment. And sometimes users are kind enough to speak publicly about their use of SAS/OR. For PROC BOM, this happened at SUGI 26 in Long Beach, CA, where Dave Jennings from Lockheed Martin Astronautics spoke (and wrote) about using SAS/OR procedures (including PROC BOM) to track and improve the process of building payload launch vehicles (rockets) for their many clients. They were able to achieve dramatic reductions in their cycle time, from receipt of the order to launch. The launch vehicles in question contain on the order of 50,000 parts, and PROC BOM performs very well at this level of detail.
You can find Dave's paper at http://www2.sas.com/proceedings/sugi26/p254-26.pdf .
In a completely different setting, PROC BOM is used to delineate a set of hierarchically related activities so that they can be scheduled with PROC CPM in SAS/OR. In this case the client is a medical service company, receiving prescription orders via mail, email, and website channels. The activities are the steps needed to verify both the prescription and the recipient and to physically fill and ship the prescription order. The set of tasks is dynamic, because subsequent steps are affected by the outcomes of preceding steps--for example, failure to make contact with the prescribing physician via one method triggers attempts via other means of communication and delays all other downstream activities. This project does not involve anything close to the volume of elements per order that the Lockheed Martin project does, but it entails a much higher volume of projects.
Thanks for your question. A lot of our SAS/OR users aren't particularly vocal about their use of the software because they consider it to be intrinsic to their competitive advantage. Because our software is licensed at the product level, we don't have any systematic way to track who is using individual procedures and how. We have to wait for them to tell us. Sometimes a user encounters a difficulty and contacts SAS Technical Support for help. Sometimes a user contacts me directly with a question or a comment. And sometimes users are kind enough to speak publicly about their use of SAS/OR. For PROC BOM, this happened at SUGI 26 in Long Beach, CA, where Dave Jennings from Lockheed Martin Astronautics spoke (and wrote) about using SAS/OR procedures (including PROC BOM) to track and improve the process of building payload launch vehicles (rockets) for their many clients. They were able to achieve dramatic reductions in their cycle time, from receipt of the order to launch. The launch vehicles in question contain on the order of 50,000 parts, and PROC BOM performs very well at this level of detail.
You can find Dave's paper at http://www2.sas.com/proceedings/sugi26/p254-26.pdf .
In a completely different setting, PROC BOM is used to delineate a set of hierarchically related activities so that they can be scheduled with PROC CPM in SAS/OR. In this case the client is a medical service company, receiving prescription orders via mail, email, and website channels. The activities are the steps needed to verify both the prescription and the recipient and to physically fill and ship the prescription order. The set of tasks is dynamic, because subsequent steps are affected by the outcomes of preceding steps--for example, failure to make contact with the prescribing physician via one method triggers attempts via other means of communication and delays all other downstream activities. This project does not involve anything close to the volume of elements per order that the Lockheed Martin project does, but it entails a much higher volume of projects.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how to run multiple linear regression models with and without interactions, presented by SAS user Alex Chaplin.
Find more tutorials on the SAS Users YouTube channel.