Best Practice questions - Modeling/Notebook Structure

Good morning ~

 

I am a new business architect with the state of Washington and I have been tasked to find a way to consolidate our existing 'project' centric notebooks into a central repository so that we can do business impact analysis when state regulations change.

 

Here are my questions around structuring this within ProVision:

 

1.  How are ProVision users structuring notebooks/repositories to model business processes across large organizations?

2.  Does anyone have any best practice ideas around naming conventions for models?   Particularly when you are modeling As is and To be processes for different program areas?

3.  In trying to consolidate my project centric models into a "Central' repository, I am thinking about creating business domains and tying the project information we have captured to date into them.  The issue that I will run into is that the majority of these projects cross domain boundaries.  For example, accounting processes cross into budget processes. 

4.  How many models can fit into a particular notebook? 

5.  How many notebooks can fit into a particular repository?

 

Any guidance is helpful....I am hoping that other organizations have had some successes and are willing to share.

 

Thanks and have a good day!

Tagged:

Comments

  • Tim,

     

    Check the Dimensions feature for the As Is and To Be. Have not used it but could help.

     

    Regards,

  • Have shared my experiences related to your questions, marked in blue. Hope you find them useful.

     

    1.  How are ProVision users structuring notebooks/repositories to model business processes across large organizations?

     

     I work on hundreds of processes across business areas in banking. Though there are many alternatives to creating a structure, it is preferable to create a common methodology across the repositories worked on by multiple users.  Having one notebook per project helps in easy administration and access of related artifacts.

     

    2.  Does anyone have any best practice ideas around naming conventions for models?   Particularly when you are modeling As is and To be processes for different program areas?

     

    There are many conventions, but OMG / BPMN methodology recommends a ‘Verb-noun’ convention. For example, Reconciliation of bank accounts process can be named “Reconcile Bank Accounts”.

    As the ProVision notebook auto-arranges the models alphabetically, would be good to pre-fix the process name with a numeric code, in case you’d like to see them in a specific order.

     

    3.  In trying to consolidate my project centric models into a "Central' repository, I am thinking about creating business domains and tying the project information we have captured to date into them.  The issue that I will run into is that the majority of these projects cross domain boundaries.  For example, accounting processes cross into budget processes. 

     

    If I need a link / reference to a model across multiple domains, the approach I use is:

    • Create the model / models first as stand-alone
    • Import’ the specific model / models into the relevant project notebooks
    • Create placeholders / sub-processes for the connections in the parent models
    • Copy the process maps in the connections

    4.  How many models can fit into a particular notebook? 

     

    There is no limitation theoretically. However, I have received feedback that the ProVision Client loses its robustness as the number of models increase, especially if drilled down into lower levels.

     

    5.  How many notebooks can fit into a particular repository?

     

    Again, there is no limitation theoretically. Have worked on upto 50 notebooks in a Repository without any problems.