PLM Processes: Flowchart vs. Rule-based?

Process management is an important aspect and activity in Product Lifecycle Management. Multiple activities in product design, engineering and manufacturing can be defined and maintained as a process. Definition of a process is an interesting problem, in my view. Different systems are using multiple techniques to define processes. Most of them are traditionally workflow-oriented. If you talk to engineers in an organization, you will discover that flowchart is widely used way to define a process. You can see below few examples of such a workflows.

We can find such definitions in all PDM/PLM systems. Definition of processes done in this way is very straightforward. However, when processes become complicated, the overall definition of a process can become a bit complicated too. You can see one of the examples below.

At the same time, definition of processes can be done verbally as a set of written rules. Such a workflow definition can be done much easier and can be easy read and interpreted by people involved into people definition. You can see a simple example of such definition created on the whiteboard.

I found both practices implemented in SharePoint Designer 2010. You can find similar implementation in other business process management systems. However, I found MS SharePoint case as a very representative one. You can create flow-based process definition using MS Visio based flowcharts.

At the same time, you can use a very interesting implementation of rule-based processes. I found such rule-based definition of processes as something that can be easier understood by users.

What is my conclusion? The ability easy to define a process is very critical. Process definition is one of the most complicated parts of PLM system implementation. To have a tool that allows you easy to understand and define processes can become an important competitive advantage for any PLM system. I think, systems are evolving and create new ways to implement processes. It will be interesting to hear what are your practices and experience in this space. I’m looking forward to you feedback and discussion.

Best, Oleg

Share

Share

Share This Post

  • Oleg – I like this idea. The key point for me is that not all people think about problems the same way. Some are very graphic (visio style) and some are more logic oriented (rules style). I’ll add this idea to the Aras roadmap. One workflow engine, one standard XML definition of a process, but 2 alternate user interfaces for the design and maintenance of that process. Let the user toggle between views (Graphical or Logical), but under the covers they are actually editing the same standard XML process definition.

  • Peter, Thanks for commenting! I Agree, there are advantages in both… To have a switch between them, probably will be cool. And this is a very engineering decision – to do both, and I can understand it. I see it very Microsoft-like too. In Windows, you can do everything in multiple ways. However, take a look on the opposite side. Apple… :).. Best, Oleg

  • Christine

    Oleg, I think you may differentiate the difference of the two approached too much. Idealistically, they both reflect the same process, and should be simply the preference of the user. Since 70% of people tend to be visually dominate (depending on whose research you believe), I really like the flow chart. However,

    I can see how the rules model would appeal specifically to the development community.
    For example, my rules based, design automation projects always start with a flow chart of sorts. Usually a hand sketch mapping variables to constraints, geometry structures, and requirements, and the challenge is to get to the rules based definition from there.

    I think the most important thing not mentioned here is that, occasionally, PLM projects go forward with faulty dataflow mapping. The best example is when Engineering puts together the model, implements the systems, and manufacturing comes back and says “But we don’t do it that way!”

    My opinion? Do it with post-it notes and yarn, but make sure everyone in the organization agrees that it is accurately reflective. Better yet, get someone from outside of the organization to come in and help mediate a baseline. It would be nice if there was a cloud-based (or open source) tool we could use in lieu of getting everyone in the same room.

  • Christine, Thanks for your insight. My take is that probably 70% of 3D CAD oriented people tend to be visually dominate… :). Seriously, what I like in your comment, is a very important point of an agreement in the organization related to a process modeling. So, what is required is not only to have a good tool, but also to get into a broader agreement in an organization about processes. To have a good tool to do it will be a competitive advantage very soon. So, post-it notes and yarn probably won’t work… To have a collaborative tool to design processes will be required. Just my thoughts… Best, Oleg

  • Paul

    Just an opposite view to throw in – the easier it is to make workflows, tweak them, make them handle ‘special cases’ the less resistance to the business defining ‘everything’ as a special case… and proliferating variation. One of the big benefits of workflow and BPM is standardisation, but if every workflow can handle lots of variation (rather than enforcing a common process) then not only does that benefit get lost, but a large development cost sneaks into the project, as well as quite a large ongoing maintenance effort.

    Paul

  • bpmintro

    Hi,

    I definetely support Christine inputs..

    After a long search, I have found Alec Sharp’s Workflow design methodology very useful. see a great presentation of his:
    http://www.slideshare.net/dafnal/alec-sharp-process-traction-presentation

    Re a cloud-based solution: check Lombardi Blueprint
    http://www.lombardisoftware.com/bpm-blueprint-product.php

    Dafna

  • Paul, Thank you! I think, this is a very interesting insight. I personally like “rule-based” definitions because of granularity and flexibility. Flowchart is great for visualization, but easy becomes messy with details and complexity. Best, Oleg

  • Dafna, Thanks for links. In my view, historically all BPMs started from flowchart. It will be interesting to see where new trends will bring us… Best, Oleg

  • Pingback: Putting the Process in PLM - Red Flags | Clarity on PLM()

  • Oleg,
    I know this is going to surprise you (because I am such a process weenie), but your post scared me. I fully agree with defining processes, but I am OK with Christine’s yarn and post-its for a lot of them. Not everything should be automated in a workflow. I have some experience implementing rules-based systems as well. The one common factor between workflow and rules-based systems is that they have a huge potential to waste resources (if they are not applied intelligently). I don’t know if that is in agreement with Paul or disagreement. They need to handle exceptions, but I have seen people try to accomodate all possible scenarios and really get themselves tangled up in a mess.
    I tried to distill my thoughts into a few simple suggestions here: http://tech-clarity.com/clarityonplm/2010/process-plm-red-flags/.

  • Jim, Thanks for your comments and write-up. I’d agree with you- process oriented system potential can waste your time. Especially when people you are working with are in the same room. This is a place where PLMs are going to the extreme by saying – everything is a process. Btw, it was my main concern in our process-related discussions in the past. However, my take in this post was on the fact that you can define the same things in two different ways – workflow and rule-set. Which one can be easy understand? That was my question. I didn’t get to the conclusion. Probably, the one I like the most was done by Peter- support both. Very engineering-oriented decision. I will think more about that again… Best, Oleg

  • Darcy Parker

    I am glad others are picking up on the power of the ‘rule based’ approach to expressing processes. ‘Rule based’ languages are ‘declarative. And in many scenarios, ‘declarative’ languages are simpler to understand, execute and verify/validate compared to ‘imperative’ languages.

    I agree that Alec Sharp’s book is an excellent resource (probably the best today) on workflow modeling. Alec Sharp’s book doesn’t really talk about the value of a ‘rules based’ approach to defining workflows. But his approach is ‘declarative’ and without explicitly using the term ‘imperative’ he warns people against the ‘imperative’ approach many lean towards when defining a workflow. Imperative expression has its place, but it can become messy fast. (Note, ‘Rules Based’ languages are declarative. But they aren’t the only style of declarative expression. For example, declarative expression can be very visual and applied to workflows.

    So workflows can be messy/difficult if approached in an imperative style. But if approached in a declarative style, the expression can be much easier. Hence Rule Based expression can look valuable against a poorly implemented/expressed workflow.

    I have been spending the last few years enriching myself on declarative languages and have found it very useful in my process work. If others are interested, I recommend researching the following topics with google/wikipedia: Declarative vs Imperative Languages, Functional vs Procedural languages. Also check out some applied cookbooks/examples for rule based languages like Schematron and XSLT. Other declarative languages like Haskell, F#, Scala, etc… are also helpful. They aren’t directly related to ‘process’ modeling of course. But they have enriched my views on how to model processes. I think there is a big future for “Rule Based” modeling of processes.

  • Darcy Parker

    “Not everything should be automated in a workflow.”

    This is definitely true. Transactional Processes are appropriate for automated workflows. But processes that are creative in nature should not be automated. It can be valuable to document a creative process at a high level to aide in education and/or management of the creative process. But these types of processes cannot be decomposed into or transformed into a transactional workflow. (As an example, change management is traditionally a transactional process. Whereas Concept Development is clearly a creative process. You can model the concept development process – but there will be gaps/creative leaps that cannot be expressed in a general sense. Therefore we need to avoid the trap of trying to workflow a process area such as Concept Development.)

  • Darcy, Thank you for sharing this information and comments! I agree, rule-based is more declarative and sometime easier to understand. It can be the right answer for financial systems and some others. However, people in engineering have a tendency to think more in terms of flow-charts. Just my thoughts… I see them moving forward on both. To develop systems that can use both and allows to define using either flowchart or rules (as Peter proposed) will be probably the best option. Oleg.

  • Darcy, this is a specially good comment in the context of various aspects of designer’s work that cannot be easy formalized as a process. Make sense… Best, Oleg

  • Pingback: PLM Think Tank – Top 5 Posts, May 2010 « Daily PLM Think Tank Blog()

  • Pingback: Process Simplification – the next goal for PLM companies?()

  • Pingback: Process Simplification – the next goal for PLM companies? « Daily PLM Think Tank Blog()

  • Hi there to all, it’s really a pleasant for me to visit this web site, it contains important Information.

  • Way cool! Some very valid points! I appreciate you penning this write-up and the rest
    of the site is also really good.

  • With havin so much content and articles do you ever run
    into any issues of plagorism or copyright infringement? My site has a lot
    of exclusive content I’ve either created myself or outsourced but it seems a lot
    of it is popping it up all over the internet without my permission.

    Do you know any techniques to help protect against content from being stolen?

    I’d certainly appreciate it.

    vrai louboutin pas cher

  • Pingback: PLM workflow dream()

  • Pingback: Beyond PLM Blog » PLM Workflow “California Roll” Style()

  • Pingback: PLM Workflow “California Roll” Style | Daily PLM Think Tank Blog()

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Messaging and the end of workflows()

  • Pingback: Messaging and the end of workflows | Daily PLM Think Tank Blog()

  • Pingback: 3.2 : PLM, workflows and product development processes - PLM BookPLM Book()

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll