Inventory Policy #

Introduction #

An inventory policy is a set of rules and guidelines for how inventory is converted, operated, or consumed in pursuit of a business object. A policy is typically informed by a mathematical model that accurately describes the behavior of inventory with respect to the business objective and can identify an optimal policy with respect to the model.

The most basic function of any inventory policy is determining what, when, and how much to order. When inventory is operated (e.g., a server), the policy needs to incorporate the additional function of what, when, and how much to remove.

Inventory behavior is typically classified as either discrete or process based.

Discrete Inventory #

Discrete inventory corresponds to distinct items that can be easily counted, touched or seen. The final product typically can be disassembled into its constituent parts, like IT hardware.

A Bill of Material (BOM) describes how individual units of raw materials, components, and assemblies are organized to compose a final product for purposes of design, build, or service. A Work Order (WO) is used to manage process steps necessary to transform constituent parts into a final product.

Analogous to BOMs and WOs, a Configuration Management Database is used by IT to provide transparency for governing configuration state changes of infrastructure inventory to enable business objectives (e.g., regulatory compliance, etc.). CI/CD pipeline tooling is used to govern and automate process steps to deliver custom software.

Process Inventory #

Process inventory corresponds to inputs that undergo a transformation, using formulas or recipes, to arrive at a final product. The transformation process may include changes to volume, density, mass, or other physical properties, and the final product cannot be dissembled into its constituent parts.

For example, refining crude oil involves separation, conversion and treatment processes to produce useable products like motor gasoline, jet fuel, lubricants, and waxes. A less complex example involves mixing a syrup concentrate with carbonated water to produce soda pop. The former is a distillation process and the latter a blending process. Both involve physical transformations of a fluid from one state to another.

Data Center Infrastructure Inventory #

Zypr delivers highly precise forecasts because it relies upon process inventory techniques to more precisely describe how data center infrastructure evolves over time. Specifically, the activity of adding more capable hardware and removing less capable ones from a pool is described as an ongoing blending process, which measures the relative change of hardware efficiency and performance (HEP) with respect to a hardware unit (e.g., a processor core).

But unlike the soda pop example in which a predefined formula specifies how much syrup concentrate is blended with carbonated soda, Zypr's job is to "identify the ongoing formulas" of the blending process that consistently results in the highest HEP — the concentrate — for the lowest total costs for all resources — the volume.

But unlike fluids, which lend themselves to "smooth" transformations described by closed-form formulas, the means by which infrastructure inventory evolves is informed by discrete units and events. Zypr therefore relies on numerical methods and piecewise operations to develop solutions and provide the formula for determining what mix of dependent resources are necessary, when, and in what quantities that minimize the ongoing total cost of a resource pool.

Zypr answers that in minutes.

Scalable Inventory Policy #

The blending processes described above represents intra-pool optimization, which by itself, offers significant savings. And as the number of pools to which Zypr is applied increases, additional savings are available by optimizing inter-pool blending.

The complexity of this more generalized "server assignment problem" is reduced using the Kratio as a heuristic. Because pools with the highest Kratio place a higher financial value on incremental gains in HEP than a lower Kratio pool, higher Kratio pools are very likely to have servers with shorter economic-life, relative to lower Kratio pools, making them more quickly available for reassignment to another pool. Therefore, the egress pathway of removed servers follows a directed acyclic flow that is relatively easy to solve. As the above image shows, no arrow line directs a server assignment to a pool from which it previously had been assigned. Of course, a removed or assigned server refers to logical assignment to a different resource pool, not a physical move.