Recipes and planning - Sensorica/valuenetwork GitHub Wiki
Recipes and planning go hand-in-hand in this system.
If you got a recipe, you can automatically generate all of the related pieces of work-to-do in the recipe. That's what we mean by a plan. The plan takes the form of orders: either customer orders or work orders. Each order contains all the components of a process flow. You specify what you want to create, and the recipe generates all of the details. A lot easier than doing it by hand.
Planning has the following purposes:
- explain what needs to be done
- lay out process flows as a framework for coordinating work
- provide signals of work to do, resources that have been created, problems that have arisen, and potential solutions to those problems
- and provide clear and easy ways for people to log their work.
In other words, if you do this, nobody should ever need to go looking for what to do. It should just come to them.
Don’t think of planning as this top-down command-and-control situation. The plans offer opportunities for people to work. They choose what to do.
Some network member could create a plan, or plans could be created in meetings. The plans are created order-by-order, one at a time, so planning does not require this big upfront effort. Can be added as needed, whenever. Some time soon, we'll add re-planning when things go wrong. And that will happen event-by-event.
The logic is pretty much the same as Material Requirements Planning (MRP), but it's event-driven, while the original MRP was an overnight batch job that planned everything at once. And it plans all of the work, equipment and space requirements, as well as materials.
But all of the above requires recipes. The first recipes we created were wrong: they were manufacturing recipes when Sensorica, the first user network, was not ready for manufacturing. They were in a state of chaotic R&D.
By chaotic R&D I mean, everybody decides on the spot what to do next, so if they wanted to log the work they did, and the resources they created and used, and tie all that stuff together in value flows, they needed to create the whole process by themselves.
So we are working on designing different types of recipes. They will not necessarily handle really chaotic R&D, but we want them to be able to handle the next stage: still R&D, but no longer quite so chaotic. When people have started to understand the patterns of R&D work. We want to be able people to be able to record that knowledge of how to do things in recipes, and generate plans for R&D work from those recipes.
If we can get that to happen, then people will find on their My Work page new tasks that fit their skills. If they take one of those tasks, they will then find it in the section of What I’ve Been Working On. If they click on one of those processes, they can log their work.
That framework is also suitable for the kind of notification-based interactions that smart phones live on.
And the recipes become part of the community's documented knowledge of how to do things.