NRP2 and flow-oriented systems

This blog post previews the mythical next generation of Network Requirements Planning systems, NRP2, which will be a flow-oriented resource management system. And contrasts NRP2 with NRP1, which was not flow-oriented, and Odoo, an Enterprise Requirements Planning (ERP) system which is also not flow-oriented, but also not for networks.

Then we'll discuss what a flow-oriented system would look like and a bit about how it might work.

NRP1 (an open-source Network Requirements Planning system)

overview of NRP1

NRP1 was a collaboration between Sensorica and Mikorizal. We expect more collaborators on NRP2.

Odoo (a dual-license ERP system)

overview of Odoo

Both NRP1 and Odoo look pretty functional, huh?

Probably designed for functional (deparmental) organizations, where you work in a functional department. Or at least that's the world that Odoo was mostly designed for. NRP wasn't designed for departmental organizations, but we were emulating ERP systems when we created it, so that functional-department view was probably a mistake.

What would a flow-oriented system look like?

For one thing, the flows can cross from one network node to another, and also travel through the internal operations of one node and then cross over to the next node and flow through the internal operations of that node, too.

Flows are like a river system where different towns (functional departments) live along the banks.

river system

Is flow-orientation something new and amazing, or did it get lost and now returns?

Flow orientation preceded ERP systems and then got (partly) lost and now returns,

ERP systems added functional-departments to a basically flow-oriented app.

The flow-oriented app was Material Requirements (MRP), which was the first business computer system that did something really new, that could not be done without computers. And then the evolution from MRP to MRPII and ERP added some functions from the past, copied from paper systems, that dammed up the flows.

MRP is a flow system

The basic pattern of MRP is Dependent Demand, where independent demands (like customer orders) are fed by dependent demands to create all of the inputs to satisfy the customer orders. So in the other direction, dependent demands flow into independent demands (the customer orders).

ERP is (mostly) not a flow system

The original sin of ERP systems was inherited from MRPII systems, which were relabeled Enterprise to appeal to big enterprises. So MRPII connected the flow-oriented MRP to a set of departmental accounting apps: Accounts Payable, Accounts Receivable, Payroll, and General Ledger. And MRPII evolved into ERP.

..but Odoo ventures into flows now and then, for example:

So let the flows flower

(I stole that name from The Weather Makers lovely flow diagramming app named Flower. Thanks, Angel and Pieter! Ok if I mention it like that? I'll give it back soon. Or if you prefer, I won't mention it at all...)

What would that look like?

NYTextileLab flows

That's a little hard to read, but you can select it and Open Image in New Tab and then enlarge it to make it readable.

The flows in that diagram go from right to left until they end up in a Raglan Sweater.

Along their path, they visit several functions, like farming, spinning, knitting, etc.

The people responsible for those functions can get their own view of the flows crossing their path, like a todo list, and the designer, who is responsible for managing all the flows in that diagram, can see her flows in that big picture.

Here's another flows view from an upcoming app from https://hrea.io/ , which probably also needs to be enlarged to read: hREA flows

Yet another view might be the flows-in-motion, which we have not created yet. So that's for another time.

But to summarize, you can get the functional view from the flow view, but you can't get the flow view from the functional view,