How to distinguish use case of Analysis and Studio?

Dear Celonis team,

It is very nice to launch new product Studio and now I am trying to create prototype in Studio for feasibility study. My interest is how to migrate to Studio because I already have multiple Analyses.

Now I have three option to use for my analysis

  1. Analysis in Process Analytics
  2. Analysis in Studio Package
  3. View in Studio Package

What is the strategy to distinguish these three options ?

Of course if I would like to add actionable components, 3 is the only choice.
But I would like to extend current analysis with Studio components for the moment, then I would like to keep using 1 if no special requirement for using Studio components.

Do you think 3 will replace 1 in the future, or parallelly use both ?
Additionally if 2 is better than 1, what is the reason for this ? I do not see reason to migrate from 1 to 2.

Best regards,
@kaztakata

Dear @kaztakata,

thank you for raising this very good question.

First of all, I would like to mention that we will shortly introduce a feature to easily migrate already existing analyses from Process Analytics to the Studio -stay tuned :slight_smile: But why would you wanna do that? And why start building new analyses in the Studio instead of Process Analytics?

The benefits of moving analyses to the Studio and building analyses in Studio are
a) you have Version Control at the Package level, there is no version control in Process Analytics
b) you can have analyses linked to different data models in the same package
c) as you mentioned, you have the possibility to combine Analyses and Views (with new visualization and actionable components) in one package and use it in parallel to leverage the benefits of both. Also extending the capabilities of analysis with view components is way easier if the analyses are already in the Studio
d) you have one place where you can maintain and build both, Analyses and Apps. Even if the analysis does not require new Studio capabilities, the use and edit experience is better if it is always in the same place.
e) Process Automation already fully migrated into Studio. The Studio will be THE place to create new content of any kind. That also means long-term, the Studio will be the sole place where you build analyses, and Process Analytics will be replaced by it at some point. With the feature we will release soon, we want to give customers and partners already a chance to explore the Studio and move the first analyses.

And as you said, the question to either build a View or an Analysis depends on what you want to achieve right now. With Views you can build persona-specific views, optimized for daily work, integrating the Task execution or defining priorities.
Currently, to provide ad-hoc analyses and drill-downs Analyses are a bit more flexible and you can achieve fast results. Long-term, as we further and further developing the Views and analytical components for Views (like the Sankey or Treemap diagram), as well as the build experience of Views and Knowledge Models, they will become more powerful and also be the first choice for analytical use cases.

If you have further questions please do not hesitate to reach out to us!

All the best
Sabeth and the Celonis Studio Team

Dear @Sabeth

Thanks for your detailed answer.
I understand your strategy to move from Process Analytics to Studio and the advantage of Studio Views, and almost I agree your idea.

One challenge I feel is smooth migration from Analysis to View. To migrate our Analysis one by one at least all components in Analysis are required to build in View, but there are missing parts like pie chart, histogram, variant explorer, conformance (I am not sure whether you judged to drop these components, or you are now building them).

Of course I am excited with new components of View like MEL process explorer, so I will partially create new Apps from scratch.

One question regarding your point b), if I can use two data models in one package, does it mean I can use two data models in one View ?

Best regards,
@kaztakata

Hi @kaztakata,

I understand. We are continuously working on extending the charting and component library for Views, right now we prioritizing to add new capabilities needed for the Execution Apps and overtime will also add the frequently used components known from the Analysis. Please feel free to raise feature requests via our Service Desk, for the components, you would like to be added first!
So right now, I agree, the main part of the analytical use case is best to be built on the Analysis, and Views are added for special use cases like the MEL explorer.

To your question regarding b). Yes , in a package you can have multiple Knowledge Models and each Knowledge Model can be linked to a different data model And on a View you can define for each component the Knowledge Model it should use. Meaning, you can display data from different data models on one View.
The Analysis is still linked just to one data model - but you can have two analyses, linked to different data models in the same package.

Best regards,
Sabeth

Just FYI

I found there is way to create histogram by chart component, so I posted how to do it separately.

1 Like

Awsome! And thank you for sharing this with our community!

Dear @Sabeth

I checked latest update and content-cli is what you mentioned ? I tried it and actually migrate existing Analysis in PA to Studio Analysis.

My further question is, do you plan to develop migration tool from Studio Analysis to Studio view ?

Best regards,
Kazuhiko

Dear @kaztakata,

The Content-CLI is one way to do this, nice that you already checked it out! We will soon (early to mid-January '21) also introduce an in-built feature to migrate a Workspace with all its analyses from Process Analytics with a few clicks to Studio, w/o using the CLI.

Great question. We are looking into how to make the migration from Studio Analysis to Studio View as easy as possible. A fully automated migration will probably not be possible, but there a lot of things we plan to do to make it as effortless as we can.

All the best,
Sabeth

1 Like