Aras Community

Welcome to Aras Community Sign in | Join | Help
Aras Community
Please Also Visit the Project Site to Download Add-Ons and Solutions
Jump to Projects

Re: Related between workflow and Activities

  •  05-15-2008, 8:44 AM

    Re: Related between workflow and Activities

    Hello Anshul,

    Some quick background on the underlying data model (ItemTypes).    You are correct that Workflow is an ItemType,  with a collection of ACTIVITY and PATH ItemTypes structured Underneath.          Project is build of a structure of  WBS_ELEMENT and ACTIVITY2 ItemTypes.    While the Activity (in Workflow) and Activity2 (in Project) are quite similar,  they are 2 separate Itemtypes.    We want to merge these in the future. 

    A Workflow can be connected to one instance of any ItemType,    I think of it as the Workflow carries one token around,  and this token can be linked to any item inside Innovator.     So it is possible to create a Workflow Map that is associated with the ItemType  Activity2,  such that there is a workflow running against each Activity2 in a Project structure.          Technically how you would do this is...   create the Workflow Map,  then edit the ItemType  Activity2, and on the Allowed_Workflows tab,  make a link to this new Workflow Map.  Then decide whether you want the workflow started automatically when the Project-->Activity2 is created (check the Default box),  or you will start the Workflow with some trigger and method of your own.  

    This begs the question...  Why?     The Project->Activity2 is already appearing in someone's InBasket as work.  The Activity2 has a structure underneath (Assignments) that can be used to partition the work of the Actiivty2 to a team of people.  Now the whole team has the Activity2 in their inBaskets.    Motorola created some fine tools for looking at the resource loading of these Assignments for one Project and across Projects.         

    In the Aras model,  each Activity2 is linked to one ore more Deliverables (costing spreadsheet, CAD drawing, specification documents, etc).  These are the actual artifacts of the work that the Activity2 represents.  Often the creation, editing and approval of these Deliverables requires many steps ie. Activity's in a Workflow.       Here's the Hierarchy that I recommend.     

                            Project --> Wbs_Element --> Activity2 --> Deliverable <-- Activity <-- Workflow

    Might not be clear in stick figures here...  create Projects for the long running, phase/gate processes,  such as launching a new product to market.   The Activities are aligned with 1 or more Deliverables and have 1 or more assigned resources.     Each of the Deliverables has a Lifecycle and Workflow of their own,  with assignments on the workflow tasks.   The Workflow is used for the shorter, faster running processes such as Authoring a CAD file and getting it reviewed and released.        The intersection is the Deliverable.     Project managers should plan down to the Deliverable level  [ what do I need,  when do I need it, and who is Responsible],  and then let the department managers and functional experts create domain-specific Workflows that ensure they produce good work product,  that meets the due date and expectations of the Project team.   


    Peter Schroer
    Aras Corp
    pschroer@aras.com
    Filed under:
View Complete Thread
Powered by Community Server, by Telligent Systems