The Production Process diagram - apps4work/co.a4w GitHub Wiki

fixme. could use some pictures. may be a 'diagram'.

Imagine a fully automated product design and manufacturing process.

A human describes what they want, and a series of robots and machines in a process orchestrated by computers turn the concept into a physical manifestation.

Draw that process on a screen.

A flowchart paradigm might be a good way to draw it. A series of processes with connections. Some processes go through does diamond shaped boxes which mean a choice of flow. In programming they represent if statements with a different flow depending on some condition.

The process boxes mean that the input is turned into a different output.

The data flow through these processes represents the digital product. Some processes would be enhancing the digital product specification, for example by determining the structure of the product in the way that a structural engineer adds to the designers plans beams to keep the house up or a technical designer adds darts to the creative designer's output to implement the appearance she wants.

In the manufacturing process the processes would be taking actions. The picture on the screen would represent a machine processing the physical product, such as sewing the dart.

fixme: add pictures of flowchart

A decision Diamond might represent a choice such as the decision to send the product to the buttonhole machine based on whether it has buttons. This might be a production planning decision since whether or not it has a button was known before the product started Manufacturing, or it might be a real-time decision such as which buttonhole machine is currently set up with the right thread color.

Each of those boxes in the drawing represents a piece of programming possibly connected to a piece of equipment. The box has inputs and the Box has outputs: they are the digital product and may represent also physical work-in-progress for the creation of the digital product.

For some boxes, there may be human input. For example the box in the design process that collects from a human wisdom on the appropriate Fabrics for this design. Another box maybe the quality assurance box which takes input in the manufacturing process from a human who decides whether the current work-in-progress meets the quality specifications. Or the input may be as simple as "yes I have done that", or "yes I approve that" for a process where the physical processor for this box is actually a human.

Imagine instead of the drawing on the screen being an after-the-fact representation of what is happening, that the act of creating the drawing is the act of constructing the development and manufacturing process, and that changing the diagram is the act of changing, or at least planning a change, to the actual development and manufacturing process.

Adding a box to the diagram adds an app to the process. Connecting two boxes together define input and the output and the processing sequence for the apps.

This implies a digital product. A computer readable, computer processable, representation of the object that is being worked on. The object that starts as a representation of the concept, gets enhanced step by step by processes in the design stage, and gets interpreted into physical actions to create the physical product in the manufacturing stage.

And of course the digital product would be used to create the product offering that is represented at the retail stage.

The boxes are apps. It implies a selection of apps. Apps that accept the input digital product and that recognize the relevant parts of that digital representation, and that produce new relevant parts of the digital representation that can be consumed by other apps.

To make this practical it requires the apps fit together like Lego bricks not like pieces of a jigsaw puzzle. Apps that are flexible in where they fit not apps that fit in the one and only place they were designed to fit. That doesn't mean magic. You will never able to fit the app that sews they seem before the app that cuts pieces to be sewn. You will be subject to the laws of logic and physics. But you should not be subjected to random restrictions caused by Data representation issues.

But nor will this require superhuman preciense. There will be Data representation issues, because history created them and imperfect foresight will continue to create them. But suppose these were just another app. If you needed to connect app A to app B but A and B were not quite compatible, then maybe you can find app C to place between to fix the problem.

You'd want a vigorous Marketplace for apps that solves problems automated specification enhancements, and controlled manufacturing steps. You would want new bright ideas on how the process can be made better or make better products or products to sell better.

You would want apps that implemented a new bright idea to be dropped into your processing system faster than your competitor could drop it into his. Or least not be the one who doesn't have it.

You might not like the flowchart paradigm for describing the sequence of operations in your design manufacturing process. May be some programmer comes up with a different paradigm for manipulating those processes and decisions. You might want to use several of them in the same way that a house designer looks at two-dimensional plans and three-dimensional representations and animated fly-throughs, as different ways of looking at the same proposed house.

These processes are "Apps For Work".

The digital product specification is also an App For Work, although you may have a harder time conceiving of a "Shirt" as an App. See Data Vs Function if that worries you.

"Apps For Work" that need to talk to humans do so by having a browser interface. All Apps for Work need to be able to show a human what they contain, and so are able to show themselves on a browser. Some Apps for Work will allow humans to change what they contain.

Apps for Work that need to talk to other Apps For Work (which is likely to be all of them) do so by using the Part Interface. The Part Interface is a very generic mechanism that allows one App For Work to ask another App For Work a question and get the answer. The same interface, look at from the other direction, allows an App For Work to provide an answer to the App For Work that is further down the process. The answer may be direct repeat the answer it got, or additions answers, or answers to questions that prior App for Work didn't know. The answers can be stored in the App For Work, or acquired of the internet or computed on the fly. you don't care. Nor does the prior or successor App. This is how Apps fit together like Lego bricks, not jigsaw puzzle pieces.

Apps for Work that make Apps For Work into different Apps for Work use the "Function Part Interface". Apps For Work that orchestrate other Apps for Works are called Apps For Works Managers. They need to be told what Apps for Work to work with, or better still find out for themselves. Apps For Work use the Part Registration interface to announce that they are available to be worked with.

"Apps For Work" are things human's manipulate, in the same that humans manipulate files or emails or MicroSD cards. A MicroSD card is actually mostly plastic and copper connections. The "meat" of a MicroSD is a silicon chip that is almost too small to see, and far too small for human fingers to manipulate or connect. Nor would normal humans know what to with it, beyond plugging it into something that knows what to do with it.

The "meat" of an "App for Work" is called a "Part" which is a JVM programming Object that programmers makes and know what to do with. A "Part" can have the "plastic and connections" added to it to make it into an "App For Work". This can be done automatically using the default "plastic and connections", which take care of the housekeeping for a default display of the part and registering the Parts existence. Except for Programmers who want to provide custom "plastic and connections", programming concentrate on the "meat": the Part.