Supporting "lite but rigorous" PLM in webERP

[dalers]

Continuation of product lifecycle status and general product lifecycle management started in Sales Orden Items with CSV with obsolete items error

@dalers

One solution may be to replace the boolean "obsolete" variable with a multi-value "stock item status" selector variable with possible values "unreleased", "released", "superceded", or "obsolete." "Unreleased" for items that are not yet approved for purchasing, manufacturing or sales (useful during the engineering product design process), "released" being equivalent to the current "not obsolete", "superceded" for the scenario described by Tim, and "obsolete" for items no longer used. Perhaps there is a way to merge this concept into webERP in a way that avoids updating the 200+ checks Ricard referred to, but I think it would be best left for another day (and another issue).

@pakricard

This is a big modification. This obsolete flag is checked around 200 times around many scripts. It might then look like a "item life cycle" more than a flag. And different types of items might have different life cycles. Happy to start a discussion about it! P.S.: I currently simulate life cycle with stock categories, but could possibly benefit from a dedicated variable to control this.

I think the best idea of this conversation, is @dalers's idea to turn this boolean flag into a multi value flag, converting this current/obsolete life cycle, into a more detailed one. If we are keen to explore this route, we'll need to decide if we set up a predefined standard life cycle or allow different installations to have different life cycles, and how to move between stages, etc.

Related discussion of a PLM'ish nature.

• Propose increase size of stockmaster StockID, Description and LongDescription Propose increase size of stockmaster StockID and Description #812

• Z_ImportPartCodes.php fails Z_ImportPartCodes.php fails #741

• Schema is missing an Item "Notes" field Schema is missing an Item "Notes" field #592

• How to Import BOMs How to Import BOMs #591

• What is purpose of Manufacturers and Brand Management? What is purpose of Manufacturers and Brand Management? #668

• BOM item quantity needs more decimal places for accuracy BOM item quantity needs more decimal places for accuracy #702

• Sales Orden Items with CSV with obsolete items error Sales Orden Items with CSV with obsolete items error #808
  (specifically comment Sales Orden Items with CSV with obsolete items error #808 (comment))

[dalers]

I propose removing the current "obsolete" boolean from the GUI but keep it in the db. If a new multi-value "life cycle status" selector was added, the logic for the "Obsolete" selection could also manipulate the existing "obsolete" boolean used in any current scripts and only new or updated scripts would use the multi-value lifecycle state.

I'm also curious @pakricard what types of product you are thinking of for which "unreleased", "released", "superceded" or "obsolete" would not suffice. You may wish more states or user-defined states, but I'm thinking these 4 would be the lowest common denominator. Parts&Vendors, the defacto standard small company Windows98 PLM software managed with only "unreleased", "released" and "obsolete" over 10 years.

[pakricard]

Hi:

We now simulate product life cycle with stock categories, with items jumping from stock category to stock category during its life cycle, with certain rules on how, when and where they jump from state to state (like a Turing machine). It works OK, even we could probably enjoy a dedicated life cycle setting.

As an example, now we have the following states for finished products:

1. Setup (likely your “unreleased”, or v0)
2. test
3. stable
4. no more production
5. discounted
6. recycle
7. obsolete

Components (stockid's only used in BOM's but not sellable as independent items) have different life cycles.

Most likely:

• a software company releasing software will have a different life cycle,
• a holding company will have no life cycle,
• a rental company could use different states too and,
• another company dealing with physical items could have more or less states for its products.

webERP caters for all kinds of business (not only in the physical items world), so we should think about all the options.

R

[timschofield]

@dalers I very much like the idea of a generalised product lifecycle management, I think it would be a great addition. I think it would need to be user defined, in order to work in all different types of organisation as @pakricard says.

Any chance of putting together a specification in the wiki? Do you have write access to it?

Tim

[dalers]

Sure, I can start a specification in the wiki. I believe I have write permission but will advise if I don't.

I'm thinking of starting with describing use cases to bound the requirements.

[dalers]

I've got a a skeleton page finished on the Wiki: https://github.com/timschofield/webERP/wiki/PLM-Features

It's a little short on details but if we agree on the Background section, I think the details should come easily.

[dalers]

I think we should keep discussion here and I'll update the wiki when a topic converges.

@pakricard

We now simulate product life cycle with stock categories, with items jumping from stock category to stock category during its life cycle, with certain rules on how, when and where they jump from state to state

I used stock categories to simulate the item types in the data I'm attempting to import (the item types are hard-coded in Parts&Vendors and all items are assigned a type). I then assigned the types to GL accounts in the Canadian starter COA.

I wonder what the effect on financial reports will be using my categories vs yours. Anyone have thoughts?

I plan to continue using my categories for grouping types of stock items and use the item Obsolete flag to manage lifecycle (i.e. either obsolete or not).

When an arbitrary lifecycle state and transition system has been developed, I would likely start with the simplest lifecycle - Unreleased, Released and Obsolete (obsolete meaning the same as it does now) and over time migrate to (or at least demo) something more complex. I expect the simplest lifecycle to be suitable for many but an arbitrary system will still be needed to "seal the deal" even if not a hard requirement).

I've also been thinking about the relationship between items and the change management decision making and control processes that affect them (e.g. the common ECR/ECO processes followed by many businesses), but haven't formulated any sort of direction or potential roadmap yet.

Any thoughts on any of this?

[pakricard]

Similar to your “I used stock categories to simulate the item types”,

We have N-1 stock categories for your CAT “finished products” products, N being the number of states an item can be during its lifecycle.

Why N-1? Because the last state is “obsolete”.

When we create an item, it starts as “FinishedItem SetUp”. The item stays there while we decide the BOM, suppliers, prices, and initial creation processes, that might include WO's, PO's, etc. So we need an StockID and start tracking its life.

Then, when it is ready to be sold, it is moved to category “FinishedItem Test”. The item stays there while it is market-tested, small BOM, prices changes allowed, etc. Then it can transition to “FinishedItem No More Production” or “FinishedItem Stable”.

“FinishedItem Stable” is where a successfully tested item spends most of its useful life, hopefully bringing sales and profits.

“FinishedItem No More Production” is where an item goes when it is decided that we will not produce / purchase it any more. Now it is time to start getting rid of current stock.

Then, if sales are slow, unfashionable or whatever reason items goes to “Finished item discounted”, where we try to get rid of current stock more aggressively.

At any time, if an item shows quality defects, or any other valid business reason, it can go to “FinishedItem Recycle”, where we dismantle the items into components (whenever possible) to recycle whatever can be recycled.

At any time, an item can suffer a “sudden death” and goes from current to obsolete, but it mainly happens in the last 3 states.

So, we have scripts to manually propose state changes (and user confirms) and cron jobs executed daily that move items from one stock category to the next, depending on some business rules. Other cron jobs track components and move the components' life cycle states, according to the life cycle of its parents items, and so on.

As one item spends its life in 3 to 6 different stock categories (it is dynamic, not static), each stock category simulates one state of its life cycle.

For components, the life cycle is slightly different. For displaying tools, consumables, etc it is also different.

So, we have plenty of stock categories to accommodate these states. Depending on how you set up these stock categories, then you can have more / fewer details on the Balance Sheet.

But, this is only how we do the life cycle now in webERP, and occasionally, we get more picky and add, remove states or the rules to change items between states. I don't pretend that this system is universally correct ;-), just works perfectly OK for us. Only needs a careful set-up and some trial and error.

I think we should allow the user to create a list of life cycle states. I can't see easily how we can allow the user to code its own rules for transitioning from any given state to the next ones, besides hard-coding it. But we could easily set a list of “next allowed states” or “next forbidden states” for each state.

Also, a set of states should be linked to some stock categories.

R

[dalers]

Hi @pakricard, thanks for expanding.

Fwiw, my goal is to support a startup product development business in a regulated industry (e.g. medical, HazLoc or general electrical safety) and still in stealth mode (before VC investment) with a certifiable (but not certified) QMS, constructed using an open source software stack: webERP augmented with WackoWiki for knowledge management, SeedDMS for document management and MantisBT for CAPA (corrective and preventative action) and non-conformance management.

This QMS would support the startup while it creates a pre-commercialization prototype or proof-of-concept and minimise risk for commercialization after obtaining VC funding. The startup would be able to invest what cash it has into product development instead of third-party business and QMS software and the business would be valued at a premium when the time comes due to demonstrated maturity and reduced risk.

It should be assumed the startup will migrate to a certified commercial QMS system after obtaining VC funding on the basis it will be less expensive in the long run than certifying the open source software stack. Consequently, the open source software stack should be constructed and configured with migration in mind (which will also contribue to its valuation).

My personal business model would be to provide the open source QMS software stack in return for equity and exit when the business obtains VC funding (or later, depending on the industry).

Does this sound like crazy talk?

[dalers]

@pakricard

So, we have scripts to manually propose state changes (and user confirms) and cron jobs executed daily that move items from one stock category to the next, depending on some business rules. Other cron jobs track components and move the components' life cycle states, according to the life cycle of its parents items, and so on.

This was especially interesting. If webERP supported an ad hoc product lifecycle and a transition request/approval workflow, do you think you would use it? Do you think your workflow scripts could be upstreamed to webERP if they were generalized? Do you think it would it be better to start from scratch, but still informed by your experience?

[pakricard]

From a lazy POV, I do not need to add product life cycle to webERP as Stock categories allows us to do it pretty decently, and it is already coded.

From an engineer POV, I would like to have product life cycle and I think it could make webERP more appealing, increasing the base of followers and maybe collaborators ;-) which is always nice.

Upstream these scripts? I guess I should convert them to the new life cycle capabilities once implemented, and then could decide. As I see it now, it is industry and business specific as the reasons to move one item from state A to state B depends on every business (and even more, circumstances keep changing inside a business, and I keep changing the rules now and then).

As example, in retail an item would pass the market test is it sells more than X pcs in Y days in Z shops in high season, but use different parameters in low season. High season and low season are very local specific parameters. Any of these rules would probably make no sense for a chemical company, machining company or car rental company, etc.

I think, to automate these change of life cycle states, it should be done case by case. It seems not realistic to me to have a general and useful way to do it, except if we create an interface to write complex rules. We have a basic one in the reportwriter, but so simple that most of the cases can't be used in the real world.

R

[dalers]

Upstream these scripts? I guess I should convert them to the new life cycle capabilities once implemented, and then could decide.

I was thinking (hoping) you might have user interface scripts that could be adapted to save work but it seems unlikely.

It sems not too difficult to provide a way for a company to configure a set of lifecycle states and the allowed transitions between them, and also provide the UI to manually transition an item from one state to another (perhaps going through a request/authorize procedure). To extend that relatively simple system, I was thinking we could provide "do nothing" rules skeleton script that a company could code their business rules in and cron would periodically execute the script to perform automatic lifecycle state transitions.

Would this compare in concept to your current system?

[pakricard]

Let me comment a bit more on the "lazy part", as might sound harsh and it is not intended.

This usage of stock categories to simulate PLM works 100% fine for us. In 17 years, I did not find a case we could not use following this system.

Maybe we could convert it to our standard life cycle system and use the developers time available for specs still not available?

Probably we need more voices here, to value each approach. Let's see what other developers or users think.

R

[dalers]

This usage of stock categories to simulate PLM works 100% fine for us. In 17 years, I did not find a case we could not use following this system.

Does your business not need stock categories in the traditional sense e.g. for financial reporting?