Goals for Demand Supply and Work sections
...of the Value Network software.
Let's use Goal Oriented Design. That means, list the goals that you as a user want to accomplish in each of those areas. Don't try to design the system features or how the goal should be accomplished, just describe the goal. Keep it simple.
Sooner or later we will need to decide how much of those goals to include in the software, but don't worry about that for now.
Suppose that the value network grows very large. Lets call a customers an agent who doesn't participate in the production of the product, but acquires the product in exchange of something else. The customer can purchase the product to resale, or to integrate it into another product. This customer might be active in another portion of the value network. Let's call these customers internal customers. On the other side, we can have customers that are not active in any way within the value network. Suppose for example that these individuals are active within the classical economy. Let's call them external consumers. Internal customers generate internal Demands. Here we can discuss about internal transactions and external transactions...
The system should be able to create and treat Demands from an internal customer and from an external customer.
For the internal demands, the system should propose at least two types of transactions: give the product in exchange of equity, or in exchange of cash.
François is reviewing the list(s) of potential customers we identified for the Mosquito, as we plan to contact and visit them soon. For now, these lists (still in construction) are on spreadsheets, and that's fine, but what about the CRM system, in order to have automation in the way we interact with customers: automatic reminders to follow-up with them regularly after meeting them, actions to take (order, custom manufacturing, collaboration), if there's a closing, a deal, who did it, who initially found the lead, + all the metrics associated with customer exploration: how many emails we have to send for one answer, what type of answer (negative or positive, leading to another contact or not), how many phone calls, cold calls or not, how many time per sale, total cost per sale, plus all the comments we report following meeting someone (was she/he friendly, why, did she/he liked the product, the brochure, the slideshow, did the demo went well, what questions they asked, does she/he has money, what type of funding, what can we improve in particular and in general ?). This also strongly relates to the demand and supply functions of the system.
I would carry the distinction made in the previous section between internal and external demand, to supply. We can have internal supply coming from another portion of the value network, from another project.
The system should be able to mix internal and external supply. The value network cannot supply everything to one project, so I suppose projects will take some contributions from other projects and some stuff from the outside.
The lead time is important, for internal and external supply, in order to be able to manage time within the value network.
Other types of dependencies are also important.
Value networks must be scalable things. All tools must work like lens. They allow individuals to focus on some aspects, in some areas. What about optimization tools for supply chains. The tool can allow the user to zoom into some areas, filter some aspects and help the user optimize some parameters: time, cost, environmental footprint, etc. The focusing effect is in fact like a filter on the entire value network. For example, I want to optimize the supply chain for the Mosquito product. That will only chose these nodes in the network that contribute to the Mosquito product.
Tentative ideas, please correct as needed
Material, equipment and other resource requirements for scheduled project processes should be posted along with the process schedule.
These resource requirements need to include both requirements for well-defined products and loosely defined or improvised R&D processes.
When such requirements are not filled by available inventory or other scheduled processes, members may choose to purchase them. Most member purchases for a network project will fill known requirements for scheduled project processes. (What happens with member purchases that do not fill any known requirement?)
A project does not purchase its own resources, but instead receives purchased resources from members or from other network projects.
Members may want reimbursement for their purchases as soon as possible, or they may want to contribute for participation in future income distributions. A project should reimburse members for purchases that are marked for reimbursement before distributing income to contributions, but once reimbursed, those kinds of purchases should stop participating in income distributions.