Virtual CCB idea: Can we use Wiki for PLM?

I think everybody knows about Wiki. (Wikipedia definitions of wiki software).

Today Wiki engines became very popular and affordable. There are a great number of available wiki platforms starting from big vendors and ending with open source and online offerings. You can take a look on Comparison of Wiki Software. Providers of Collaborative Platforms and software classified as Enterprise 2.0 also supplies Wiki capabilities. You can see some successful examples of Wiki usage presented on Enterprise 2.0 conference in Boston this year (Successful enterprise-level wiki implementations). Big providers like IBM, Microsoft and Oracle are including wiki capabilities in their offering.

There are newcomers in Wiki space – Semantic Wiki. The example of semantic wiki is Semantic MediaWiki and some others.

Do you think we can do leverage Wiki in PLM? I’m coming with an idea to implement, for example, ECO management system based on Wiki engine. Today ECO implementation in an organization requires intensive organizational work mostly going beyond of software and technology. This work is focused on understanding of how an organization processes works. By implementing CCB (Configuration Change Board) activity as Wiki we can create a self learning system that can absorb current practices in the organization. Since Wiki Engine provides flexible content aggregation and integration capability this WIKI CCB can evolve and be integrated with another enterprise software – PLM, ERP, SCM and others.


Share This Post

  • Perhaps I haven’t considered the concept thoroughly enough yet, but what about the timing/urgency issue? CCB through workflow provides a time-specific call to action to each CCB member, “please study this problem as soon as possible and provide input”. Is a Wiki too passive to garner the necessary level of attention? Is accountability / credit for good ideas clear enough in a Wiki? Would a threaded discussion be more appropriate as it would continue to expose the trains-of-thought over time rather than compressing them into the latest collective wisdom (as a Wiki does)?

  • Wiki CCB is not going against workflow or processes. They can work together. Wiki can provide good sharable mechanism for interactive dashboards between people involved into CCB. Process/Workflow is moving activity – what you call “time specific call”. Workflow and Process like activity provide accountability. Wiki provide place to share/study situation, aggregate all relevant inputs – collective wizdom.

  • Wiki certainly has the advantage from the perspective of capturing the decision for historical purposes. I still like the idea of threaded discussion to understand how the group’s thought processes evolved, but 1 year after the ECO is approved, the Wiki will be a very relelvant, concise piece of reference information to answer the typical question, “why did we decide to make this change?”

    On a separate thought, do we believe that a Wiki can be rich enough to support the different communication mechanisms that take place in a CCB? For example, if two people in a live CCB meeting want to markup a drawing (together), is the analogue possible in a Wiki? Wouldn’t a collaborative web session be more appropriate? So perhaps I am raising the issue of an asynchronous collaboration being difficult. But then again, many people participate in asynchronous CCBs through PLM workflow today.

  • First of all I’m not taking wiki as universal hammer for all CCB or ECO problems :)… this is, in my view, good way to boost initial CCB activity. Since underline technology is very flexible it can be easy enhanced and integrated with existing or future systems. But entry barrier on such technology in organization is very low in my view.

  • I can confirm the idea has merit. I sent 2 years building out this idea in a startup. The solution is not as simple as you would want. The problem with PLM is there is to much structure and constraint and the problem with a wiki is there is to little structure and constraint. Also I would offer the point that discussion and wiki are not the same. Both are required but they are not the same. The solution I worked on was a structured wiki. The reason is a plain wiki leaves everything up to the team to organize (this work for a few things, but more than 3 and you are in trouble). But if the system presented the user with structure based on what the user wanted the page to do, then the wiki “concept” works. Also if you allow the team to define data/parameters within the project that can be used on each page then the user gets to define a data structure for each page… My current team has worked on the discussion side of this problem and we are launching a beta/prototype this week The prototype currently works with Proe and through the web. You create a discussion fro within your CAD session and the disucssion is automaticly tagged to be about this file (or any selection within the file, could be a feature). Now anytime anyone ones this file the serve will let them see the discussion that took place about this design. We call this connected item the context or the target. I think you can see how a wiki page can become a target… The reason is that while some people on the team think of a part being designed (say the Handle) by the CAD files, or excel files, other memebrs of the team do not. For instance the project manager or the procurement person thinks in terms of the Handle and when the talk to the CAD oppoerator they don’t say new_handle_v1.prt, they say Handle. So what if the wiki had a page type that was Part and this page was connected through discussion? Now the page is truely a clearing house for the Part/Handle… What if you had another page type Action and you could link an action page to a part page? If you think this works then you should stay tuned to

  • Chris, will be interested to see your wiki project. Will stay tuned :).. Oleg

  • mickey_bigdaddy


    what’s the latest on the wiki project? i am very curious to learn more, your links are not working anymore.