So I've started to read Vollman. Definitely considering APICS certification but have a lot more to think about before understanding whether that makes sense.
Attempting this enterprise requires careful thinking about all of the assumptions. Introductory material is especially important because it sets the context. What is MPC? Vollman Page 1:
"The MPC [Manufacturing Planning and Control] system is concerned with planning and controlling all aspects of manufacturing, including managing materials, scheduling machines and people, and coordinating suppliers and key customers . . . truly effective MPC systems coordinate supply chains -- joint efforts across company boundaries. Finally, MPC systems design is not a one-time effort; MPC systems need to continuously adapt and respond to changes in the company environment, strategy, customer requirements, particular problems, and new supply chain opportunities."
How do we understand this challenge in terms of enterprise IT service management? Again, I re-iterate that the scope of the current project is infrastructure: up through the middleware at the furthest.
What does it mean to "manufacture" in a service context? There are two aspects:
Been working with my three-lifecycle model for a while now (also here) and it is holding up in the lab so far. (I have an ITSM laboratory called my day job, as an enterprise ITSM architect for a large US bank.) Can't talk too much about that side of things but the reader can assume I'm not going to keep blogging about dead ends.
The chevrons show the true processes. What do they have in common? They all are conceptual entities as well, candidates for entity lifecycle analysis. Furthermore it is interesting to consider the average duration of their lifecycles:
According to Plossl, one of the initial differentiators of MRP versus previous approaches was in the understanding of demand.
It may seem obvious that if you have orders for 10 cars, you will likely need 50 wheels and 20 headlights (assuming you are providing spare wheels). But it's less obvious that you might need 250 lugnuts and 3000 type A45 left-threaded fasteners (OK, I made that last one up).
I have been posting about "ERP for IT" for some years now. While I have been generally familiar with the history of ERP (Enterprise Resource Planning) and its origins in MRP (Materials Resource Planning), my background is in the social sciences and software engineering - not operations research or industrial engineering.
The relationship of software development to industrial engineering has been uneasy. I believe that attempts to make software development more predictable through increased process rigor and measurement have been at best partially successful. Yes, software development can be treated as engineering. Is it always optimal to do so? That is the question.