Odoo 10: 10: MRP Draft Spec Introduction (done) Workflow (done) (done) Master Data (done) Picking Types (done) Product Category Bill of Materials (done) Form view (done) Why we remove remove valid from/valid until? (done) Search View (done) (done ) Remove properties (done) Routings (done) (done) Operations in parallel in a in a routing (done) Work Centers (done) Introduction: Introduct ion: Time Clocking (done) Specifications: form view (done) (d one) Specifications: Scheduling (done) Specifications: Spe cifications: KPIs (done) Manufacturing Operations Manufacturing Operations (done) Manufacturing Orders (done) Introduction: Int roduction: MO vs Work Orders (done) MO: Bill of Material without routing (done) MO: Bill of Material With Routing (done) Scheduling (done) State and Material availability (done) Costing (done) Unbuild (done) Work Orders (done) Work order: form view (done) Work Order: Planning (done) Work Order Kanban (done) Work Order Gantt (done) Work order: misc (done) Work Orders Planning Rework (done) Procurements Introduction 1/58
Time-Phasing / Time Buckets (done) The new scheduling algorithm will consider future demand, and create future supply, based on small time periods. These small time periods are called buckets. By default, the time buckets have size of one day. Using time-phasing, we delay orders for components until the day they are needed. Low-Level-Coding Menus & Filter (done) Form view (done) Manual Routing Product form (done) Product Configurator & Variants Product configurator Buying Matrixes Generic Grid View (done) SO Related Matrix Dashboards (Foreman) Dashboard: floor plant Work center control panel (done) Sequence of Operations (done) Work sheets / work instruction (done) Scheduling (done) Traceability (done) Touchscreen (done) Product Lifecycle Management (PLM) (done) Extra fields for PLM (done) Engineering Change Orders (done) Communication (done) Maintenance of Machines (done) Introduction (done) Equipment (done) Maintenance (done) Preventive maintenance (done) Maintenance Request (done) Menu (done) Master Production Schedule (done) Quality (done) Introduction (done) Scrap (done) Quality Control (done) Quality Control Objects (done) Quality Alerts (done) Objects (done) Random notes to specify (done) 2/58
Time-Phasing / Time Buckets (done) The new scheduling algorithm will consider future demand, and create future supply, based on small time periods. These small time periods are called buckets. By default, the time buckets have size of one day. Using time-phasing, we delay orders for components until the day they are needed. Low-Level-Coding Menus & Filter (done) Form view (done) Manual Routing Product form (done) Product Configurator & Variants Product configurator Buying Matrixes Generic Grid View (done) SO Related Matrix Dashboards (Foreman) Dashboard: floor plant Work center control panel (done) Sequence of Operations (done) Work sheets / work instruction (done) Scheduling (done) Traceability (done) Touchscreen (done) Product Lifecycle Management (PLM) (done) Extra fields for PLM (done) Engineering Change Orders (done) Communication (done) Maintenance of Machines (done) Introduction (done) Equipment (done) Maintenance (done) Preventive maintenance (done) Maintenance Request (done) Menu (done) Master Production Schedule (done) Quality (done) Introduction (done) Scrap (done) Quality Control (done) Quality Control Objects (done) Quality Alerts (done) Objects (done) Random notes to specify (done) 2/58
Statistics Reports: SPC (done) RMA (Return Merchandise Authorization) Menus (done) Configuration Contract (purchase agreements) (done) Blanket orders (done) Technical Specification (done) Split of Modules Workflow Business cases PLM: Two different departments: engineering and production department Indented BoMs and history Being able to change the product in all BoMs because we don't want to use the component anymore. Corrective vs. preventive maintenance MPS: MTO orders, but MTS raw materials
3/58
Introduction (done) Most MRP software on the market are old, very complex and not efficient for the users. Moreover, companies usually have to use different software to handle their MRP needs: MRP, plm, maintenance, quality, ... Those are usually not part of the same software. With the Odoo technology, we think we have a serious opportunity to disrupt the market. The MRP module has two different modes / ways of working: 1. by manufacturing orders (bom orders (bom without routing): for companies that just need a todo list of manufacturing orders to process, ordered by expected date. There is no work centers planning or resource assignation, but it's also easier as you only need to manage bill of materials, not routing. (small companies that mostly do assembly and do not need to assign tasks amongst different work centers) 2. by work orders (bom orders (bom with routing): for companies that need to track and plan operations over different work centers. In such a mode, workers work on a work center (can be a machine or a person) and perform operations defined on the routing, linked to the manufacturing order. Some of the software we analysed: ● Arena: Arena: quite good PLM. It has the feature we need and could be a reference for a PLM implementation. We can get inspiration from Arena for the list of fields/features, but we have to rethink the usability. As opposed to Arena, our PLM should be fully integrated with the WMS/MRP modules. (example, after an ECO you decide what you do with old products that you replaced in the BoM…) ● Frepp Frepple: le: Ope Open n Source Source Prod Product uction ion Plan Plannin ning g ● Plex: Plex: Plex’s usability is bad but their business features are good. It’s one of the most “mrp oriented” software we have seen. ● QAD: a referen reference ce for for APICS APICS based based manu manufact facturin uring g softwar software e (http://www.qad.com/solutions/manufacturing) ● Netsuite: Netsuite: quite bad, but one of the rare MRP solution in the cloud. So, it's worth having a look at it. ● Rootstoc Rootstock: k: I don’t don’t know know it, but it looks looks good. good. ● Aras ( Aras (www.aras.com www.aras.com). ). ● All community modules already modules already developed on Odoo 8. Once the first draft of this document is written, we plan to read all community modules to check if we did not miss something important. ● IBM Maximo: Maximo: for the maintenance section only ● To test: http://pinpointinfo.com/ ● OdooPLM OdooPLM alread already y integrate integrated d in odoo, odoo, with cad capabil capability, ity, revision revision and and workflow workflow on document and product (I will be at the workshop, with a live demo if needed) . 4/58
●
Infor Infor XA ERP ERP which which is insta installed lled world worldwide wide to to more more than than 2’000 2’000 cus cu stomers. This ERP is designed mainly for manufacturing companies and is same generation as SAP (Year 80’s) Others knowledges are based on European cost accounting (Costing) rules used by many from our manufacturing customers.
Workflow (done) A typical workflow: workflow: ●
●
●
●
Procurem Procurements ents (sales (sales order order in MTO, MTO, minimum minimum stock stock rules, rules, pull pull flows) flows) create create new manufacturing orders that are directly confirmed by Odoo, but not planned (they are ordered by scheduled date by the scheduler) The manufacturin manufacturing g planner planner can can plan plan those those orders orders to assign tasks to to the work centers. centers. At that time, work orders are created and their start/end date is computed based on work center capacities and availabilities. The worker worker can can start start working working on a work work center center and proce process ss all work work orders orders related related to this this work center. He only sees work orders that are ready. When working on a work order, he can mark products that are consumed or produced, do quality checks, see the work sheet, etc. Once the the worker worker start start a work order, order, this this may mark mark the manuf manufactu acturing ring order order as “In “In progress”. Once the worker finishes the latest work order of a MO, this will mark the manufacturing order as done.
Departments and their main roles: ● ● ● ●
Engi Engine neer erin ing: g: bom bom,, prod produc ucts ts Manufact Manufacturin uring g Enginee Engineering: ring: routing, routing, workshee worksheett Manufa Manufactu cturin ring: g: mo, mo, work work order, order, work work cen center ter Logi Logist stic ic:: proc procur urem emen entt
Roles: ● Logistic Logistic/Man /Manufac ufacturin turing g Managers: Managers: may validat validate e procureme procurement nt (and, (and, thus, launch launch manufacturing order or decide to buy/subcontract). Depending on the push/pull rule, it can be automatic (default) or require a manual confirmation on the procurement. ● Production Planner: he plays plays with manufacturing manufacturing orders orders and and work work orders: orders: planning planning and and material assignment. He can prioritize manufacturing orders to impact the work orders planning, or the quantities to produce. ● Workers: Workers: they they only work work on a specif specific ic work center center,, processi processing ng work work orders orders as they arrive. Inventory: 5/58
● ●
At every work order, we may consume products (or not), or produce products (finished goods or by-products) The latest work order produce every product that are not linked to an operation: finished goods, by-products, and raw materials. (because these ones have already been recorded)
6/58
Master Data (done) Picking Types (done) Currently, the picking types can be of 3 kinds: internal, incoming, outgoing. We will extend this list to add a fourth one: “Manufacturing Operation”. It will be displayed in the kanban view of picking types (stock dashboard) as well, and we will design a specific card for manufacturing operations that will show MRP related information, shortcuts…
That way, you can create different Manufacturing zones (by warehouse, company, etc) and you can define specific routes attached to each picking types. (e.g. trigger a picking to prepare products to manufacture)
Product Category Note: not sure we need to implement this feature. (phase 2 or 3)
7/58
Add in the product category an integer field “Time frame (days)” which will be used for the grouping of procurements into the same PO/MO. More info in section on procurements.
Bill of Materials (done) Form view (done)
On the bill of material components, we can select a work operation, the one where raw materials will be consumed. (a many2one). If nothing is set in this field, products are consumed at the latest work operation. If some products are consumed in multiple work centers, we have to deduplicate the line in the bill of material. Same features for finished products. The idea is to relate components from the bill of materials to operations in the routing. Mainly because raw materials and finished products are consumed/produced during work orders operations (coming from the routing). The name of the field should be “Consumed in Operation Sequence #” (not “consumed in Work Center” as shown in the above screenshot) Add a selection field “Ready to produce”: ● When all products are available ● When the products of the first operation are available 8/58
Remove the fields: ● Internal Reference: as a “Reference” field already exists ● Sequence (keep this field in the tree view (drag_handle), but remove from the form view) ● Remove the fields: valid from & valid until on the Bill of Material ● Remove the fields: valid from & valid until on the BoM lines (*) Replace the active checkbox by a “Archive/Unarchive” top button, on the top bar like in other documents. (Add a filter on “Archives”) Add a related button on the top that opens the tree view of the bill of material (including all sub-levels of nested BoMs). The following fields should not be in Technical Features: valid from, valid to, rounding, efficiency, active (but it’s converted into a button in the topbar). They should always be visible in the “Miscellaneous” tab. By-Products should also be linked to routing operations, like bill of material components. Log any change on the BoM (or BoM lines) in open chatter. Add a field picking type (domain=[(‘type’, ‘=’, ‘manufacturing’)]): when a procurement has a ‘produce’ route with a picking type set, it will try to create a Mo for that product using a BOM with the same picking type (if there is no → exception). That allows to define pull rules for products with different routing (different BOMs)
Why we remove valid from/valid until? (done) When you need to change a BoM, you rarely replace a component in a BoM at a specific date. Usually, when you do an engineering change request, you have 3 options: exhausted (replace the BoM when the deprecated products are consumed) or ASAP (when logistic/manufacturing engineer are ready), or manually. For each of these 3 options, we use a date (an estimate time of application). This date is just an estimation to sync all the departments: manufacturing engineering should change the process and worksheets, logistic should order new components, manufacturing should train the worker… This date is on the ECO (Engineering Change Order) and you can apply the new BoM in one click from the ECO. It never happens on a specific date at midnight as you can not take the risk to apply a BoM change automatically if one of the department is not ready (what if manufacturing-engineer did not had time to apply changes on the worksheet for the deadline? Or vendors did not ship the 9/58
raw materials on time). Sometimes a change apply on several BoMs/routing that can be done on different dates --> the process takes 3 days. It’s also risky to manage changes using Valid from, valid until → If some dates overlap, you have two time the component in the BoM. It’s also not clear for the readability of the BoM. For these reasons, the ECO gives all information to update a BoM / routing / worksheets, … But the application of the ECO is always done manually (you just need to press a button) and never automatically by the system (at a specific date).
In short, we have different BoMs that does the history. (when we want to make a change on a BoM, we can duplicate the existing one and have another that is not in production yet). We have an estimated date, but the application should be triggered manually to avoid blocking a line in case of issues. More over, keeping the history of a bom change within a bom is a bad practice (for readability), it’s better to keep old BoMs as separate, deprecated, BoMs.
10/58
Search View (done) Since the Bill of Material is created by the Engineering department and the routing is created by the Manufacturing Engineering department. We will create a filter on Bill of Materials “No Routing”. That way, the Manufacturing Engineering can easily check the bill of material to complete. Add a “Archive” filter to show archive BoMs Add a search on the work center. (bill of material containing an operation using this workcenter) Add a search on a component “where used”.
Remove properties (done) Remove everything related to properties: properties, properties group, … Indeed, the feature of selecting the BoM directly from the SO can now be achieved by routes and picking type on BoM, so the properties are redundant. (or variants)
Routings (done) We plan to have two modes: ● Easy: no routing & work order, only BoM and Manufacturing Orders ● Advanced: a many2one on the BoM: routing_id allowing to share routing from one product to another. Routing operations have a sequence that define the order they can be launched. Sequence are not in form view, but we use a widget=”handle” in tree view. Operations are always in series, one after each other. Operation
Sequence
Reference
Drill
1
OP/0006
Saw
2
OP/0007
Lathe
3
OP/0008
Assembly
4
OP/0009 11/58
In the above example: ● You must start by the drill operation ● Once the drill is started (even if it’s not finished!), you can start saw ● Once saw is started (even if it’s not finished!), you can start Lathe ● You can do the Assembly once Lathe is started It’s possible to have all work orders open in parallel. Use case: you have a bill of material of 100 PCEs and you work in a pull flow where you produce the pieces one by one. After having produced the first finished product (going through the 4 steps), all the four work orders are in progress. Move the “production location” field on the bill of material, instead of the routing, since routing are now integrated in BoM. This production location should be editable in the MO. Operation should have a reference field with a unique sequence (can be used through the barcode interface or to refer to a specific operation when talking to people).
Operations in parallel in a routing (done) The design we choose is to have all operations in series in the routing, we do not support operations in parallel. Another alternative would have been to create a graph of dependencies between operations, but the usability would have been much more complex. Let’s suppose you have the following line, that has lots of operations in parallel: (pretty common in the automotive industry)
In the above example, sub1-sub2 and sub3 are manufactured in parallel. To manage this in Odoo, you will create 4 bill of materials (and, thus, 4 routing): one for the main assembly line, and one for each sub-product. So, when you want to run operations in parallel, you just split into sub-products. Same for the example below, you will have 3 manufacturing orders, and 2 sub-products.
12/58
Another example could be a line that support operations that can be launched in any order:
In this example, with 5 operations, the routing can follow the red or the green path. The way to organize this in Odoo is to define a default path (ex: red line). And “force readiness” on the work order 3 if you want to follow the green line. A routing line should have a clean name_get/name_search as we will have a many2one on bom.line to routing_line object. ● name_get: WORKCENTER/Operation Name ● name_search: workcenter OR operation name OR reference
Work Centers (done) Introduction: Time Clocking (done) In most manufacturing industries, the manufacturing engineering team measures the time they need to perform the operations (time study). These theoretical times on routing operations are used to compare the actual performance with the expected one. We usually follow best practices of the industry in our specifications, but this practice is very time consuming and not very efficient. (there are always good reasons to be off-timing: process change, …). It’s even a bad practice as workers tend to produce slowly if the theoretical times are too high. ( Parkinson’s law ) We think it’s easier and more efficient to report all actual times with a simple control panel on the work center and report the performance based on average times and variances (standard deviations). The statistical variances across all production is a better KPI than the distance between theoretical times and real ones.
13/58
If you want to detect where you can improve the performance (speed loss, quality loss, or machine break), the best KPI you have is the standard deviation. In other word: if you are able to produce some pieces faster than others (or some slower than others), check why. The actual comparison with theoretical times is less efficient and more time consuming. It’s also a huge effort during the implementation of the ERP since you have to report all theoretical times on work centers (and most SMEs don’t have this) If you base all your reporting on actual time, you don’t need this anymore. You get in real time the work centers where you can improve (standard deviation is high) and the optimum target (the faster of all these productions, which is more correct than one-time measured time). This method also better adapts itself to process change. As a summary, we still allow to set theoretical time on workcenters and routing operations. But these are mostly used for the planning when we do not have enough sample to base scheduling based on average times. All times (setup & cycle) are measured. To analyse the efficiency, we report on the average and the standard deviation (variance). As the user does not have to fill in times anymore, the usability is much better. Moreover, the statistics on the performance is more accurate and better adapt to process changes. There is no setup time and time after production, just a fixed time (setup + post-production) and variable time (per cycle). On the work center control panel, they can register their time, with three (setup time, production time, clean-up time). Of course, this approach only works if you are able to measure actual time on work orders. But we think that, if you are not able to do it, reporting on average times during a day for a whole manufacturing line does not give good enough insights to detect inefficiencies in your process. Technically, it means that time fields on workcenters and routing operations are computed, instead of being set manually. This makes the creation/definition of new work center super easy as there are not a lot of fields to fill in. But this “actual time” can be setup initially to some values, for example when you start a new routing. (it’s not exactly a computed field) So, we still support time study, but just to kick off a new routing or a change in an existing routing.
14/58
15/58
Specifications: form view (done)
If the computation is based on real time, we use the average time for one piece of the last X (10 in the above example) operations. If no work order have been done yet, Odoo will allow you to set a default time for the first planning.
Rate To reach a deep operation calculation detail we need to introduce “cost line”. To each WC we need to fulfill annually estimated costs by “cost line” and we need to estimate the “annual time” we plan to consume on WC. On “cost line” we need to share: direct cost who are the cost spend into the WC himself (eg salary for employé) and indirect costs who are shared to many WC (eg production manager salary). To calculate the rate: divide each cost line / annual time means we have a cost rate x cost line. For calculation of item operations we can have 1 amt x cost line. This help to know if company cover the fixed expenses by dept who is the break point, who are the manufacturing cost into each item and help manager to take decisions Eg of WC / cost line WC1000 = CNC engine, company plan to work 1’000 x year . direct cost - cost line A (fix) = WC employee salary EUR 80’000 x year - cost line B (fix) = WC employee social cost EUR 30’000 x year 16/58
- cost line C (fix) = amortization cost EUR 30’000 x year - cost line D (var) = electricity, oil EUR 5’000 x year . indirect cost - cost line M (fix) = management salary EUR 10’000 WC1000 will have following rate for employees - A = EUR 80.- (80’000 / 1’000 hours) - B = EUR 30.- (30’000 / 1’000 hours) - C = EUR 30.- (30’000 / 1’000 hours) - D = EUR 5.- (5’000 / 1’000 hours) - M = 10.- (10’000 / 1’000 hours) - Total rate is EUR 155.For pre-calculation (master data) and post-calculation (MOs) we could have deep cost analysis. WC1000 will have following rate for foreman / trimer - single rate is enough, don’t need to have so deep requirement - this rate is used only to calculate setup It is not good to eliminate time field “after prod” and cumulate it with setup because people who are working on those times don’t have same rate. To reach the effective rate we need to have - real costs for “WC / cost lines” who came from accounting (in manufacturing the costs must be charged on WC/cost lines and on MOs routing) - real consumed time (cumulated based on time job on/of) - real rate x cost line (used by MOs costs follow-up)
Specifications: Scheduling (done) Even if the time of the operations are computed, one should be able to set a time manually on a work operation by changing the start or the end date. (for the use case when you don’t have a correct time yet, you want the planning to be correct). The form view should have a button “Reset Averages Time” that sets the Average Reset Date to today. This is used when the process changed, you should press this button to reset the averages so that they directly adapt to the new process. We should also add a function here that write this average times into theoretical ones, particularly usable when we use Standard Costs reevaluated per month/quarter and so on. This method should be callable from a list of work operations, or a routing. 17/58
Regarding scheduling there is another requirement to have good result: queue time. (time before production and time after production, set on the work center) Before we can start an operation, we have a queue from the previous MO. We need to have a fixed queue time that help to schedule correctly operations. We need to have average queue time, corresponding to the average of time between the previous operation start date and the real operation start date. This average queue time help to analyze what we setup into standard queue time. Without queue time on WC the operation scheduling will not consider the time to wait before start an operation. Set all time and duration in minutes, not in hours.
Specifications: KPIs (done) Add the following computed fields: ● OEE (Overall equipment efficiency) --> computed field (speed loss, downtime loss, quality loss) ○ Speed loss: based on real time registered on WO ○ Quality Loss & Availability losses: based on blocking mechanism
Manufacturing Operations (done) Manufacturing Orders (done) Introduction: MO vs Work Orders (done) So, depending if the bill of material has a routing or not, you must: ● plan work orders, produce on work orders (if routing) ● produce directly (if not routing)
MO: Bill of Material without routing (done) If the bill of material has no routing, you can produce from the manufacturing order, a button “Produce” is visible, once you click on it: ● it does all the operations, according to the quantity set on the manufacturing order: consume all goods, produce finished products and by-products, close the manufacturing order. 18/58
●
If the finished products is managed by lots: ○ A wizard opens asking for a lot number (finished products), then lots numbers of raw material related to this finished product, ○ Then, next finished product, etc.
The quantity on the manufacturing order can be changed before launching the “Produce” button. So, you can produce a different value than what is requested by the system. But the raw materials are always a direct relation of the quantity produced (according to the BoM). Manufacture required more and more to produce partially (eg: MO original qty = 1’000 ; each time we produce 80 to 120 pieces then we have to update finished qty and consume components. We should have the possibility to produce many time partial quantities. So, we only keep two one2many fields on the manufacturing orders: ● Products to Consume (label changes into Consumed products once done) ● Products to Produce (label changes into Produced Products once done) Remove the following fields: ● Produced Products (add a related button) ● Consumed Products (add a related button) ● Scheduled Products Remove the “Produce” wizard. We always produce the quantity set in the manufacturing order. (but this quantity can be changed in the form before launching the production).
MO: Bill of Material With Routing (done) If the related bill of material has a routing, the main operation is to first plan Work Orders, then process all the work orders, instead of using the “Produce” button. Cfr section on work orders for more information.
Scheduling (done) Manufacturing Order’ states are: confirmed → planned → in progress → done ● confirmed: a MO to be done (generated by Odoo or created manually, different than in v9) -> create WO in draft ● planned: WO have been planned ● in progress: first WO is started ● done: MO is marked as done (usualy, when all WO are completed, but not necessarily)
19/58
The logic is the following: ● All MO are created in draft, their expected date is computed by the scheduler and it defines their priority. (the v9 algorithm is good for that, nothing to change) ● A user (the planner) can plan MOs, one by one (draft → planned). The button will create related work orders update state to “planned”. The start date of work orders are computed in a ASAP algorithm starting of today based on work center availabilities (without using the date on the MO) Thus, the order in which the planner plan MOs is important for the scheduling. If he validates a whole list of MOs at once (from list view), Odoo will plan them based on their priorities (thus, expected date) Manufacturing orders have an expected date (that is usually not updated, it’s computed by the scheduler, based on customer expectations. The current algorithm is good for that). The scheduled start/end date on MO are computed automatically based on the min start/max end of work orders. These are computed field with an invert method. If you change the start date on a MO, all work orders are recomputed accordingly. Manufacturing orders have the following fields (the version 9 state field is splitted in two concepts): ● State: Draft, Planned, In Progress, Done, Cancelled. (no more confirmed, confirmed=draft) ● Inventory Availability: Fully Available, Not Available, Partially Available (enough to start) → computed field depending on the availability on the WO. Remove the workflow. The workflow can be removed, to the benefit of more flexible transitions. The transition “In Progress → Done” is set manually, or proposed by the system when the latest WO is finished for the full quantity. (it’s a proposition requiring a manual action, never automated) The priority between manufacturing orders is defined by the tuple “priority, expected date”. By default, all manufacturing orders have the same priority, but you can start reorganizing them in kanban to change priorities. We should have three dates on manufacturing order: expected date, start date, end date. The expected “end” date is computed by the scheduler and never changed. (it could come from the promised date to the customer so it serves as a reference) The planner changes the start date if he wants to reprioritize: it’s a computed field (coming from WO) with an invert method. (gantt or calendar) The expected date should usually not be changed (you can change it if you changed the promised date to customer). The end date is only set when the MO is closed or is computed based on the latest work order. (it’s an actual date, not a scheduled) 20/58
