Да, у нас есть Партнерская программа для вузов, можно перейти по этой ссылке: http://www.elma-bpm.ru/partners/university.html там подробная информация.

Спасибо, с размахом работаете. Обязательно подам заявку.

Да, я тоже поддержу приятное впечатление Эдуарда, молодцы!

ELMA в основном позиционируется как система управления работами: выдать или принять задание, организовать маршрут его выполнения, проконтролировать дисциплину выполнения и в конечном итоге оптимизировать процесс (возможно).
Интересно можно ли реализовать алгоритм Голдрата (описанный им в книге Цель) или иную модель управления?

Можно ли дать сравнительную оценку с Comindware Tracker (здесь наш опыт его использования - статья в материалах конфренции http://objectsystems.ru/objectsystems2013/)

Разрешите внести уточнение, мы всё-таки позиционируем себя как система управления бизнес-процессами. По поводу Голдратта - да, такая возможность в ELMA заложена. Возможность непрерывного совершенствования - одно из главных преимуществ системы. Реализовать в системе можно произвольную модель управления,  стоит только ее настроить в самом начале работы, в дальнейшем ее можно развивать без длительных остановок системы, для этого есть всё необходимое.

Дальше, если сравнивать с Comindware Tracker, наша система имеет другую архитектуру, на мой взгляд, более понятную. Взять хотя бы KPI. У нас очень интересная система мотивации, которая также предполагает возможность выбора механизма оценки.

Да и в целом, всё чётко, у каждого решения свои конкретные цели: CRM+, ECM+, KPI, Проекты+. И отдельные отраслевые решения  прописаны для различных сфер бизнеса. В Comindware Tracker более сложные настройки, сложно разобраться интуитивно. А еще наши специалисты первыми в России перевели нотацию BPMN 2.0 на русский язык. Для пользователей работать с системой на русском языке всё же удобнее. Это, конечно, далеко не все различия. Например, возможности интеграции также вызывают сомнения. Информация о них как-то размыта, тогда как у ELMA большое количество специально разработанных модулей для быстрой интеграции с другими системами. На более глубокий анализ нужно время.

Разрешите внести уточнение, мы всё-таки позиционируем себя как система управления бизнес-процессами.

Уточнение принимается Извините.
А если образно, о в чем отличие управления бизнес-процессами от управления задачами (работами)? Разве БП - не последовательность задач, работ?

По поводу Голдратта - да, такая возможность в ELMA заложена. Возможность непрерывного совершенствования - одно из главных преимуществ системы. Реализовать в системе можно произвольную модель управления,  стоит только ее настроить в самом начале работы, в дальнейшем ее можно развивать без длительных остановок системы, для этого есть всё необходимое.

На Comindware нам это сделать полностью не удалось. Это связано с особенностью виджетов Comindware. Больше удалось сделать с BizAgi Studio.
Однако думаю тут проблема в исходном процессе и невозможностью получить реальную рабочую нагрузку на систему

Дальше, если сравнивать с Comindware Tracker, наша система имеет другую архитектуру, на мой взгляд, более понятную. Взять хотя бы KPI. У нас очень интересная система мотивации, которая также предполагает возможность выбора механизма оценки.

Ну это понятно, и это мы узнаем в ходе будущей работы:)

Отлично, что Вам всё это откроется 
По поводу управления БП.. Не стоит сводить суть бизнес-процессов только к управлению задачами и работами, хотя, увы, так происходит в большинстве компаний. Кроме операций есть еще основные (сквозные) процессы, связывающие элементы организационной системы между собой и оптимизирующие взаимодействие подразделений. Также через процессы реализуется управление эффективностью компании. В общем, ELMA смотрит шире на процессы)

Отлично, что Вам всё это откроется 
По поводу управления БП.. Не стоит сводить суть бизнес-процессов только к управлению задачами и работами, хотя, увы, так происходит в большинстве компаний. Кроме операций есть еще основные (сквозные) процессы, связывающие элементы организационной системы между собой и оптимизирующие взаимодействие подразделений. Также через процессы реализуется управление эффективностью компании. В общем, ELMA смотрит шире на процессы)

Да, именно это и хотелось бы услышать. Как это происходит? Можно какие-то примерчики?

На примере компании "ПартКом", где внедрялась и не раз уже улучшалась система CRM (уже 5 лет наши клиенты): изначально они хотели оптимизировать клиентский сервис. Мы применили свою концепцию - повышение эффективности через сквозные бизнес-процессы. Если подробнее, то быстрая обработка звонков, автоматизация рутины, главное быстрое взаимодействие подразделений. Сейчас у них работает наше приложение CRM+. Есть интеграция с сайтом компании (интернет-магазином, продают автозапчасти), с 1С, с колл-центром.
То что карточки клиентов открываются автоматически при поступлении звонка... расписывать не буду, это частности. Главное, что сейчас внимание всех отделов направлено на продажи. В системе все объединены в едином информационном пространстве, каждый видит текущую ситуацию по сделкам и клиентам, показатели свои и своих подразделений, результаты, общаются они в этом же пространстве по актуальным вопросам. Работать можно вообще в любом месте и в любое время по Интернету, решать задачи по работе, участвовать в бизнес-процессах и работать с клиентами. Все включены в работу.

То есть все сотрудники стали мобильнее, бизнес-процессы исполняются быстрее, и главное удобство взаимодействия, как с клиентами, так и между собой. То есть создан фундамент, и сервис можно улучшать в дальнейшем, что и происходит. Добавляются инструменты, модель управления при желании можно менять, улучшать процессы - ELMA BPM дает эти возможности.

Да, большое спасибо за ответ.

Вопрос не праздный на самом деле. У меня опыт небольшой, но имеется. В частности в нашем "Восточном экспрессе", довольно давно реализован механизм с условным названием "Поручения и работы". Т.е. есть некий бизнес или бизнес-процесс (мы его называем направлением деятельности). В рамках этого направления деятельности можно создать Поручение, которое закрепляет ответственность. На основе поручения планируются или генерируются работы (т.е. элементарные задачи). В принципе это сильно похоже на решения типа ComindwareTracker, но при этом очень сильно интегрировано с учетными функциями, аналитическими задачами.

Ну например, есть деятельность связанная с обслуживанием клиента, в ходе ее выявляются те или иные проблемы, потребности и т.п. С этой целью созданы документы и интегрированы с механизмом Поручений и работ. Причем на уровне настроек. Т.е. алгоритм такой:
- составляется жизненный цикл поручения и работ по нужному направлению
- в рамках ЖЦ настраиваются действия, последействия, и т.п.
- в нужных документах также настраивается ЖЦ и реализуется связь с поручением по направлению деятельности и еще много чего.

Мой опыт использования Comindware, BizAgi, Unify показал, что это выполнить там практически невозможно, а если возможно, то только с привлечением компании разработчика. А в Вашем случае это обеспечивается как-то? Или все вопросы интеграции осуществляются только с вашим участием?

И последнее, можно ли сказать, что ваша система отвечает SOA? Или я пальцем в небо?

Спасибо

У ELMA есть встроенный модуль SOA Connector, ELMA и внешние системы могут обмениваться друг с другом данными и влиять на работу друг друга. Подробнее описано здесь: http://www.elma-bpm.ru/functions/soa.html

по остальным вопросам чуть позже отпишу. Срочное задание

А в Вашем случае это обеспечивается как-то? Или все вопросы интеграции осуществляются только с вашим участием?

У нас приложение ECM+ позволяет встроить документооборот в процессы компании. На любой стадии процесса можно "вклиниться" в процесс, создать документ, "нарисовать" подробно его маршрут. И все заинтересованные лица еще автоматически получают уведомления о его дальнейшей "судьбе"), прохождении этапов и т.д.

Интересно можно ли реализовать алгоритм Голдрата (описанный им в книге Цель) или иную модель управления?

Эд, в книге "Цель" нет алгоритмов. Ни одного. Там изложены принципы. А прикладные решения (алгоритмы) следует выбирать в зависимости от типа производства.
* Для стабильной А-цепочки подойдет решение Форда.
* Для стабильной Т-цепочки модель производства Тойота.
К сожалению, производство софта это производство с высочайшей вариативностью. Для маленьких, простых проектов с единственным рабочим центром некие прикладные решения есть. Но как только у тебя хотя бы два рабочих центра, все становится сильно хуже. Именно ввиду сложности разработки прикладных алгоритмов TOC такие методологии, как XP, SCRUM, разработаны для одного РЦ (маленькие простые проекты).

И, да, канбан для разработки ПО не применим в принципе. От слова никак.
Подробнее смотри: http://habrahabr.ru/post/139194/

Взять хотя бы KPI. У нас очень интересная система мотивации, которая также предполагает возможность выбора механизма оценки.

"Если производительность труда программиста можно поднять при помощи зарплаты, то этого программиста нужно немедленно уволить."
(с) Андрей Орлов.
Как то Орлову я верю больше. Как никак опытнейший менеджер. Да и Деминг высказывался по этому поводу достаточно определенно.
Т.е. ваш KPI, это, скорее минус, а не плюс системы.

Т.е. ваш KPI, это, скорее минус, а не плюс системы.

Согласна с тем, что "при помощи пряника можно и убить" энтузиазм. НО. Рекомендую Вам почитать внимательнее про наше KPI-решение. Так как Вы ошибочно предполагаете, что оно основано на банальной схеме с премированием персонала. Хотя истинная цель ELMA KPI не материальное вознаграждение сотрудников, а воспитание сильных кадров, профессионалов внутри коллектива.

Согласна с тем, что "при помощи пряника можно и убить" энтузиазм. НО. Рекомендую Вам почитать внимательнее про наше KPI-решение. Так как Вы ошибочно предполагаете, что оно основано на банальной схеме с премированием персонала. Хотя истинная цель ELMA KPI не материальное вознаграждение сотрудников, а воспитание сильных кадров, профессионалов внутри коллектива.

1. Каким образом ваше KPI отделяет общие причины вариаций от особых? Это вопрос принципиальнейший. Т.к. путать общую и особую причины вариаций - один из самых страшных грехов менеджмента. А разнообразные KPI, как правило их путают и, в результате, имеет место попытка компенсации общей причины вариации с неизбежным как восход солнца печальным результатом (смотри правила воронки Деминга).

Возможно, ваши KPI их не путают. Но уточнить надо.

2. Величайшие менеджеры XX века Эдвард Деминг и Эли Голдратт очень негативно отзывались о KPI. Причем Голдратт наглядно показал, что использование KPI напрямую противоречит управлению по ТОС. Иными словами "Отмена KPI является необходимым, но недостаточном условием перехода к управлению по ТОС."

Далее гипотезы:
1.  Я неверно понял этих великих.
2. Деминг и Голдратт не правы.
3. Использование KPI может дать положительный эффект при переходе от полного хаоса к минимальному упорядочиванию, но очень быстро они станут тормозом на пути улучшения. Дополнительным обязательным условием будет: "в системе есть особая причина вариации и KPI нацелены на ее компенсацию"
4. Использование KPI не дает положительного эффекта ни в одном из случаев.
Вроде все перечислил.


Вероятность гипотезы "2" стремится к нулю.
Из остальных, я бы поставил на "3"
Если что, верифицировать "1" можно обратившись к эксперту по ТОС. Например, к Андрею Степенко.

Но несмотря на то, что я допускаю существование ситуаций, в которых KPI был бы полезен,  я не рекомендую его применение по следующим причинам:
1. Вместо внедрения KPI, как правило, дешевле выявить особые причины вариаций и устранить их.
2. Внедрение KPI без хорошего знания природы вариаций - это как игра в русскую рулетку. Причем число патронов - это число показателей, а число гнезд в барабане - на единицу больше. Учитывая, что мало кто знает разницу между общей и особой причиной - шанс выстрелить себе в голову неприятно велик.

Насколько я понимаю, ничего же не мешает "выявить особые причины вариаций" и устранять их вместе с KPI, а не "вместо".