хотел поинтересоваться есть ли в планах Runa пункт описания показателей эффективности отдельных опреаций процесса
ну и второй вопрос касается API аудита, для подключения стороних систем для сохранения истории исполнения БП
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RE: есть ли в планах Runa пункт описания показателей эффективности отдельных опреаций процесса
С показателями - сложно. Разным предприятиям требуются совершенно различные показатели. Кроме того, эти показатели зависят от схем конкретных бизнес-процессов: в одних узлах надо что-то вычислеть, а другие (какие-нибудь оповещения) надо полностью игнорировать. Сами данные у нас хранятся, но универсальных форм отчетов по показателям придумать пока не удается. - Сейчас мы для каждого конкретного клиента делаем отгрузку данных для необходимых ему показателей в какую-то учетную систему (Alfresco или просто SQL-таблицу и т.п.), а уже по этим данным приложениями-отчетами строим требуемые показатели.
RE: API аудита, для подключения стороних систем для сохранения истории исполнения БП
Специального API для аудита пока нет. Проблема в следующем у нас есть Java-классы, через методы которых можно получить множество всех событий, связанных с экземпляром бизнес-процесса и время, кода они произошли. Однако, если мы захотим сделать какую-то статистическую обработку этих данных и при этом будет "вытаскивать" все эти события из всех экземпляров, то это приведет к неприемлемому времени работы отчетов, т.к. работа с этими данными не оптимизирована по скорости выборки. Какие-то конкретные решения не приводят к заметным результатам, т.к. показатели у всех сильно отличаются (например, есть универсальное решение - вставлять в бизнес-процессы специальный элемент, потом автоматически генерировать отчеты по среднему времени прохождения точки управления между любой парой таких элементов, но оно не очень востребовано).
В общем, - пока просто ботами отгружаем требуемые данные в отдельные системы, занимающиеся анализом этих данных.
Если у Вас есть какие-то идеи-предложения по API для аудита, - напишите. Рассмотрим, если будет полезно многим пользователям, - реализуем.
Regards,
Andrei
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) по KPI (КПЭ), конечно я не имел ввиду жесткий перечень. тут я предлагаю определять глобальный переченьпоказателей (примерно как роли).
для каждого показателя хорошо бы завести еще и возможные измерения в которых может учитывыаться значения КПЭ (период обязателен, далее произвольные аналитики). В простейшем случае можно и без измерений.
Каждый КПЭ привязывается к дереву целей (присто иерархический справочник).
для каждого КПЭ в задании можно определить планеовое значение (либо констанду, либо переменную, либо выражение)
потом в рамках БП - каждую опреацию(этап) можно связать с песколькими КПЭ значения устанавливаются либо константой либо на основе переменой (или выражение).
получается: один квадрат я связал с 2-мя КПЭ, второй вообще не связывал. При выполнении БП все значения КПЭ складываются в определенную таблицу (если будут измерения для каждого КПЭ - своя таблица).
по итогу выполнения множества БП, мы можем проводить анализ определенных КПЭ.
примеры КПЭ:
1. затраты времени = прмер автоматического расчет = времени исполнения задания
2. затраты ресурсов руб. = либо задается константой для каждого задания в шаблоне, либо определяется на основе переменной
можно проводить план-факт анализ.
3. премия менеджеру = % от выполнено заказа без рекламаций
и пр.
2) по API больших идей нет
конечно при использования аудита система должна несколько притормаживать, зато остается аудиторский след.
пример можно посмотреть в параметра настройки WWF (вернее WCF) http://msdn.microsoft.com/ru-ru/library/ms733025.aspx
делается примерно так
<system.diagnostics>
<switches>
<!-- Workflow WWF
Use the one of predefined values:
All Logs all messages received
Off Does not log any messages
Critical Logs only messages that are deemed critical
Error Logs critical and error messages
Warning Logs critical, error, and warning messages
Information Logs critical, error, warning, and information messages
Verbose Logs critical, error, warning, information, and verbose messages
<add name="System.Workflow LogToFile" value="1" />
-->
<add name="System.Workflow.Runtime" value="Error" />
<add name="System.Workflow.Runtime.Hosting" value="Error" />
<add name="System.Workflow.Runtime.Tracking" value="Error" />
<add name="System.Workflow.Activities" value="Error" />
<add name="System.Workflow.Activities.Rules" value="Error" />
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Мы советуем для расчета KPI использовать отдельную систему. В узел-Действие, в котором надо учитывать KPI, предлагается поставить обработчик (событие - "по окончании задачи"), который отгрузит в систему расчета KPI все необходимые данные, а уже в этой системе будут сделаны отчеты по KPI. (У нас есть опыт использования для этого как системы Alfresco, так и просто набора SQL-таблиц и набора отчетных форм на основе JSP)
Возможно, в будущем мы добавим заготовку такой системы в проект, но пока у нас еще не сложилось представление о ее наиболее востребованной функциональности.
RE: 2)
Вопрос не в том, вести, или не вести аудит. - Аудит у нас ведется, все относящеся к экземпляру процесса события записываются. Непонятно, в каких структурах данных надо хранить данные аудита, чтобы можно было быстро их обрабатывать. Разные показатели используют совершенно разные данные, эффективное хранилище общего вида спроектировать не получается. Поэтому мы предлагаем делать специальные хранилища данных под конкретные виды вычисляемых показателей. Тогда отчеты будут быстро работать.
Regards,
Andrei
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
хотел поинтересоваться есть ли в планах Runa пункт описания показателей эффективности отдельных опреаций процесса
ну и второй вопрос касается API аудита, для подключения стороних систем для сохранения истории исполнения БП
RE: есть ли в планах Runa пункт описания показателей эффективности отдельных опреаций процесса
С показателями - сложно. Разным предприятиям требуются совершенно различные показатели. Кроме того, эти показатели зависят от схем конкретных бизнес-процессов: в одних узлах надо что-то вычислеть, а другие (какие-нибудь оповещения) надо полностью игнорировать. Сами данные у нас хранятся, но универсальных форм отчетов по показателям придумать пока не удается. - Сейчас мы для каждого конкретного клиента делаем отгрузку данных для необходимых ему показателей в какую-то учетную систему (Alfresco или просто SQL-таблицу и т.п.), а уже по этим данным приложениями-отчетами строим требуемые показатели.
RE: API аудита, для подключения стороних систем для сохранения истории исполнения БП
Специального API для аудита пока нет. Проблема в следующем у нас есть Java-классы, через методы которых можно получить множество всех событий, связанных с экземпляром бизнес-процесса и время, кода они произошли. Однако, если мы захотим сделать какую-то статистическую обработку этих данных и при этом будет "вытаскивать" все эти события из всех экземпляров, то это приведет к неприемлемому времени работы отчетов, т.к. работа с этими данными не оптимизирована по скорости выборки. Какие-то конкретные решения не приводят к заметным результатам, т.к. показатели у всех сильно отличаются (например, есть универсальное решение - вставлять в бизнес-процессы специальный элемент, потом автоматически генерировать отчеты по среднему времени прохождения точки управления между любой парой таких элементов, но оно не очень востребовано).
В общем, - пока просто ботами отгружаем требуемые данные в отдельные системы, занимающиеся анализом этих данных.
Если у Вас есть какие-то идеи-предложения по API для аудита, - напишите. Рассмотрим, если будет полезно многим пользователям, - реализуем.
Regards,
Andrei
1) по KPI (КПЭ), конечно я не имел ввиду жесткий перечень. тут я предлагаю определять глобальный переченьпоказателей (примерно как роли).
для каждого показателя хорошо бы завести еще и возможные измерения в которых может учитывыаться значения КПЭ (период обязателен, далее произвольные аналитики). В простейшем случае можно и без измерений.
Каждый КПЭ привязывается к дереву целей (присто иерархический справочник).
для каждого КПЭ в задании можно определить планеовое значение (либо констанду, либо переменную, либо выражение)
потом в рамках БП - каждую опреацию(этап) можно связать с песколькими КПЭ значения устанавливаются либо константой либо на основе переменой (или выражение).
получается: один квадрат я связал с 2-мя КПЭ, второй вообще не связывал. При выполнении БП все значения КПЭ складываются в определенную таблицу (если будут измерения для каждого КПЭ - своя таблица).
по итогу выполнения множества БП, мы можем проводить анализ определенных КПЭ.
примеры КПЭ:
1. затраты времени = прмер автоматического расчет = времени исполнения задания
2. затраты ресурсов руб. = либо задается константой для каждого задания в шаблоне, либо определяется на основе переменной
можно проводить план-факт анализ.
3. премия менеджеру = % от выполнено заказа без рекламаций
и пр.
идеи можно посмотреть во многих продуктах, например тут http://piter-soft.ru/automation/functionality/#KPI_func
2) по API больших идей нет
конечно при использования аудита система должна несколько притормаживать, зато остается аудиторский след.
пример можно посмотреть в параметра настройки WWF (вернее WCF) http://msdn.microsoft.com/ru-ru/library/ms733025.aspx
делается примерно так
RE: 1) по KPI (КПЭ)
Мы советуем для расчета KPI использовать отдельную систему. В узел-Действие, в котором надо учитывать KPI, предлагается поставить обработчик (событие - "по окончании задачи"), который отгрузит в систему расчета KPI все необходимые данные, а уже в этой системе будут сделаны отчеты по KPI. (У нас есть опыт использования для этого как системы Alfresco, так и просто набора SQL-таблиц и набора отчетных форм на основе JSP)
Возможно, в будущем мы добавим заготовку такой системы в проект, но пока у нас еще не сложилось представление о ее наиболее востребованной функциональности.
RE: 2)
Вопрос не в том, вести, или не вести аудит. - Аудит у нас ведется, все относящеся к экземпляру процесса события записываются. Непонятно, в каких структурах данных надо хранить данные аудита, чтобы можно было быстро их обрабатывать. Разные показатели используют совершенно разные данные, эффективное хранилище общего вида спроектировать не получается. Поэтому мы предлагаем делать специальные хранилища данных под конкретные виды вычисляемых показателей. Тогда отчеты будут быстро работать.
Regards,
Andrei
API есть: https://github.com/processtech/runawfe-free-server/blob/master/wfe-core/src/main/java/ru/runa/wfe/audit/ProcessLogVisitor.java