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:
First, we must conceive of the market opportunity for the service, design, acquire components, and assemble to a production-ready state. This seems highly analogous to manufacturing. In a way, the IT operation can be equated to an enormous shop floor, where the assessment, acquisition, installation, and support of manufacturing equipment has become so large and ongoing that it is seen as its own value stream. Sort of a "shop floor for the shop floor."
Thought experiment: we hear often that the core differentiator between product and service is that products can be stored where services must be simultaneously produced and consumed. Consider a lathe. It is itself a product. But the worker experiences it as a service: a service for removing extraneous material. That service cannot be stored; it must be produced and consumed simultaneously, and requires ancillary services: space, power, light, and so forth, as well as a consumer (the worker). Product and service are two sides of the same coin... people don't want drills, they want holes, as Levitt said .. but the lathe itself must be specified, ordered, received, paid for, uncrated, assembled, and checked out. And what if your organization is receiving 500 lathes a month? That is the problem facing the large IT service provider.
Second, and probably better understood, operating the service is somewhat akin to manufacturing. Starbucks employees "manufacture" coffee. As Schroeder notes (page 3), "it may appear that service operations don't have much in common with manufacturing operations. However, a unifying feature of these operations is that both can be viewed as transformation processes..."
I am currently more interested in the first perspective: the assembly of 500 lathes a month seen as "manufacturing." There are a number of interesting requirements, constraints, and dynamics.
First the "lathes" are actually physical computing devices. As we've noted, they need space, power, and cooling. The space in turn consumes security services. They also require network connectivity and increasingly the storage is virtualized. (I don't understand I/O virtualization well enough to incorporate it right now). Any undercapacity in this dependent demand results in the server not being provisioned as expected.
Why are servers so important? They, like applications, are a sort of universally accepted shorthand for a complex aggregate capability. They represent an access point, an interaction channel between the functional application/service world and the infrastructure world. They can be virtualized - in all my metamodels I have distinguished between servers as a running OS instance, versus physical machine that comes in through the loading dock. But even as a virtual service they are infrastructure; they do not add direct business value. They are dependent demand, but within that framework, they are a primary subassembly.
Managing servers is tricky, especially due to Moore's Law. In some cases the computing resources (CPU, RAM, memory) they represent are fungible. In other cases, they are tightly coupled to particular configurations. The promise of grid computing is to increase the fungibility. How can we understand and manage the transition process from configuration-bound to fungible? It will outlast most of our careers... "MPC systems need to continuously adapt and respond to changes in the company environment..."
The bill of materials problem keeps coming up. We need a general architecture for forecasting an IT bill of materials, and each assembly within it. The forecast needs to be based on independent demand, as best we can define it. Particular components need to have their demand profiles driven by the overall independent demand concept. But locally, they also need to consider obsolescence, both internally and also external obsolescence that compels upgrades (for example, hardware that will no longer run an otherwise serviceable software package.) Dynamic price/performance points need to be figured in as well ($2000 worth of new CPU next year will deliver more capacity than $2000 this year, in general). And at this point, I need to do more reading. The data structures necessary for capturing woolly forecasts, iteratively firming them up, and finally executing on them are not yet obvious to me. Does anyone have a reference conceptual data model for BOM forecast to retire lifecycle?
-Charlie
