Форум портала FineXpert.ru

Коллеги, приглашаю вас обсудить мою статью. Буду благодарен за мнения, замечания и пожелания.

В статье есть тезис, что BS работает медленно. У меня на 2-х ядерном процессоре формирование графических схем выполняется без всяких тормозов. Ни движок MS Visio, ни BS практически не тормозят.
Система реально тормозит при:
1. раскрытии дерева справочников процессов и субъектов (если там много объектов);
2. при формировании отчетов.
3. прочее.
Пример. Выгружаю положение о департаменте, которое включает в качестве приложений 6-7 положений об отделах. Процессов описано мало. При этом выгрузка отчета занимает 4-5 минут.
Много это или мало? Считаю, что это приемлемо с точки зрения бизнес-моделирования. Дело в том, что затраты времени на анализ процессов, согласование и внесение изменений в систему занимает гораздо больше времени, чем выгрузка собственно выгрузка отчета. Поэтому скорость выгрузки абсолютно не критична.  8)

Лично у меня опыта роботы с ПО для моделирования БП нет, не считая MS Visio. Данная статья оказалась можно сказать ознакомительной с «Бизнес-Студией», хотя общее представление я имел и даже немного разобрался в демо-версии. Соответственно трудно оценить насколько адекватен материал, но понравилось "разжеванность" и наглядная иллюстрация. Обилие ссылок на различную литературу тоже порадовало.

С неудовольствием буду ждать, но с удовольствием прочту последующие статьи.

Ёще один момент. По отчетам.

На мой взгляд, механизм формирования отчетов действительно не идеальный. Но не согласен с тем аргументом, что раздельное существование списка привязок отчета и шаблона отчета в MS Word является недостатком.

На мой взгляд, все наоборот! Имея набор привязок, можно его копировать, модернизировать и использовать в других отчетах. Это очень удобно при настройке отчетов под конкретного заказчика. В противном случае пришлось бы делать все заново.

Кстати, в "Бизнес-инженер 5.0"., похоже, так и приходится делать.

Я считаю, что объединение настройки визуального шаблона и структуры привязок - мысль правильная. Туда и будем двигаться.
Но (спасибо, Володя, за замечание) при сохранении возможности копировать сами привязки.

Кстати, эта проблема исправлена в выходящей скоро версии 3.6. Спасибо клиентам с 50 000 элементам в оргструктуре ;)

Смотрел, как сделано в "Бизнес-инженер 5.0" (в презентации). Там внутри шаблона в MS Word стоят кнопки типа "Данные", а название привязок системные. Все это не удобно.
Кроме того, одна и та же привязка может несколько раз использоваться в документе. Пример, название должности - раз 15-20 легко в ДИ может встречаться. Если плодить кнопки, то документ будет не читаемым, форматирование поплывет и т.п. Как думаешь?

Думаю, что кнопочный подход ставит крест на идее форматирования шаблона "под себя".

Коллеги, спасибо за комментарии :)
Хочу отметить, что я не называл разделение работы над отчетами на логическую часть и оформление недостатком.
Действительно - к этому стоит просто привыкнуть.
Вместе с тем - этот механизм не гладкий и требует еще доработки, например - информация в колонтитулах обновляется через раз. В готовом документе приходиться вручную щелкать по "обновить поле".
А в целом - это шаг вперед. Еще недавно форматирование должностных инструкций из BPwin-а я описывал макросами в экселе :)

Странно. У меня с колонтитулами все ОК. Работает отлично. Все обновляется. М.б. проблема была с версией MS Word?

Отдельно хочу прокомментировать этот Володин тезис:

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

Я считаю, что в наш век обрести популярность могут только программы, обладающие интуитивно понятным интерфейсом, ибо все меньше людей, которые могут найти время на чтение инструкций, хелпов и документации. Программа должна сама направлять пользвателя, давать подсказки и комментарии.
Что касается BS, то в своем классе продуктов интерфейс у нее, на мой взгляд, самый удачный. Но, тем не менее, куда его развивать, нам понятно и этой задаче мы уделим очень большое внимание в следующей версии.
Второй аспект, который я упомянул - это встроенная система документации, которая должна быть способна ответить на любой возникающий вопрос пользователя в процессе его работы. Первый шаг в этом направлении уже сделан - в Business Studio можно навести мышку на любой параметр объекта и получить о нем справку в виде хинта. Тут же можно нажать F1 и перейти на описание элемента в объектной модели. На мой взгляд, это действительно ноу-хау, такого больше я не видел ни у кого. Но опять таки, на этом останавливаться мы не будем ;)

Александр, напишите, пожалуйста на support@
Я думаю, проблема решаема, в крайнем случае в отчет можно вставить макрос, обновляющие поля после формирования.

Как и обещал, скажу еще несколько слов по мыслям, изложенным в статье.
Еще раз хочу поблагодарить Александра за глубокое погружение в систему Business Studio и за найденное время для написания статьи (и статей в будущем). Побольше бы таких пользователей! :)

Как я уже говорил, во многом я согласен с мнениями Александра. Практически все, что он написал находится в той или иной стадии планирования или реализации. Поэтому я прокомментирую только отдельные моменты:
1. Если при использовании программы, что-то к сожалению сходу не ясно, то сразу нужно обращаться в суппорт. Там направят в нужном направлении. Это я про создание справочника терминов. Неделя, которую Вы потратили на решение этой задачи, конечно было потрачена впустую. Нормальное время - 5-8 часов для человека, который делает это в первый раз.
2. Часть замечаний относится к разряду "хочется, чтобы было по другому". Сам люблю делать такие замечания, но, к сожалению, зачастую они сталкиваются с суровой действительностью, которая продиктована существующими в отрасли техническими решениями. И когда ты понимаешь, почему нельзя сделать, так, как ты хочешь, легче принимать то, что есть :). Поэтому несколько слов по поводу быстродействия.

Да, BPWin был быстрее. Да, я тоже хочу, чтобы BS работала также быстро. Но! Вспоминим, что есть BPWin - это работа с файлом, это дясяток разных справочников.
Что такое Business Studio? Это информация хранящаяся в промышленной СУБД, это поддержка совместной работы на уровне отдельных объектов или диаграмм ( а не целиком файла), это обновление данных при совместной работе (Зря Вы, Александр, удивляетесь, совместная работа в BS - это норма) , это более 200 различных справочников для хранения модели компании.
Поэтому, конечно, BS загружает данные из БД постоянно, а не один раз загружает файл, как BPWin  и далее работает с ним в памяти. Именно поэтому BS не показывет диаграмму сразу, как только Вы вставли на процесс, а требуется явное указание (двойной клик или, кстати, есть кнопка в навигаторе) для загрузки диаграммы.

3. "На диаграммах нет участников процесса." Слишком строгое замечание. В диаграммах нотаций Процедура и EPC они есть.
Что касается автоматического добавления исполнителей, указанных как механизмы на IDEF0.... Мы их добавим :).

4. "Авторам программы неплохо былобы добавить возможность отражения на блок-схеме не только исполнителей, но и времени"
Сделано в выходящей скоро версии 3.6. Ксати, "продюсером" этой возможности был Володя Репин:).

Недавно нужно было быстро нарисовать схемку процесса в стандарте IDEF0. Так вот, начал делать в BS - понял, что слишком долго (чисто по скорости нажимания кнопок, работы со стрелками и т.п.). Открыл BPWin и сделал нужную схему за 10 минут. Очевидно, в BPWin удобство рисования диаграммы на высоте - ничего не скажешь. Но вот с точки зрения создания объектной модели организации и выгрузки регламентов эта система не решает нужных задач. Поэтому альтернативы BS нет. Даже некорректно сравнивать BPWin с BS, имхо.
Кстати, "тяжелые" западные системы очень похожи по архитектуре на BS. Имею в виду Casewise.

(С прищуром), понимаю, что это уже не рисование диаграммы, но ты попробуй исполнителей задать или объекты навесить на стрелки (ха-ха-ха) в BPWin... ;)

Почему с прищуром? Нельзя критиковать святое?  ;)  Надо вспомнить историю BPWin и тот факт, что можно описать подробно данные по стрелкам, а потом экспортировать в ERD-модель ERWin-а. Но это уже не по теме. Мы же статью обсуждали...

Коллеги, добрый вечер.
Выставляю на ваше суждение вторую статью.
Надеюсь, окажется полезной пользователям программы.

Статья очень понравилась. На мой взгляд, довольно объективно рассмотрены сильные и слабые стороны продукта.  А из второй части сам узнал кое-что новое, что упустил, читая руководство пользователя.

Считаю, что подобные честные обзоры очень полезны и для разработчиков, я бы, например, был бы очень рад, если бы кто-то объективно раскритиковал Fox Manager ФМ.

Добрый день!

Прочитала две части статьи. Статья интересная и полезная. Буду писать по пунктам:)
1. По поводу путаницы с электронным и бумажным документом. Мне кажется все вполне логичным. Например, у нас есть документ "Регламент", он все равно будет для меня бумажным документом, потому что у него есть "твердая" форма, которую будут подписывать и согласовывать. А документ, например "Товары в пути" - это электронный документ, который печатать и подписывать нет необходимости.
2. Про то, что много преднастроенных отчетов. Так это же прекрасно!!! Можно создать копированием отчет и ломать его до посинения:) И точно знать, что он до этого работал, и если не работает после наших изменений, так это наши изменения. В принципе, все ДИ (например) содержат одинаковые пункты (права, ответственность и т.д.), а недостающие можно добавить. Думаю, что гораздо быстрее и проще взять уже настроенный отчет, добавить и/или удалить привязки, настроить шаблон. Чем "с нуля" строить отчет. Как пример - я брала стандартную ДИ, добавляла содержание деятельности ко всем процессам, удаляла показатели, отредактировала шаблон и получила достойный результат за короткие сроки. Это все же быстрее:)
3. Потери верхнего колонтитула с лихвой компенсированы в свойствах процесса, где так же есть и автор, и дата создания. Что тоже выводится в отчет, только в виде привязок-объектов.
4. Много нужно сохранять. О, это просто песня))) Могу точно сказать, что чем больше сохранений, тем ЛУЧШЕ! В таких случаях всегда вспоминаю анекдот:
xxx: очередной раз зашла сотрудница из соседнего отдела. вопрос из топ-10: "Закрыть-сохранить-нет! Все пропало! Что делать?"
yyy: писать Биллу. Чтобы он добавил "Точно не сохранять?"
5. И про принцип доминирования в IDEF0. Нужно ли соблюдать строго этот принцип или стоит все же располагать элементы на диаграмме, руководствуясь здравым смыслом, чтобы схема была читабельна, не было "узлов" и "бантиков" из стрелок?

Kaloshina, да, несомненно, БС – лучшая программа в мире, а то, что программа предлагает каждый раз сохранить диаграмму, даже если никакие изменения внесены не были, это вовсе и не недоработка, а, наоборот, забота о потребителе. А элементы в IDEF0, конечно же, нужно располагать, не так, как задумано авторами нотации, а так, чтобы не было «узлов» и «бантиков». Все документы в компании следует делить исключительно на те, которые есть смысл подписывать и те, которые нет смысла даже печатать.  
P.S. Это не наезд на программу, это ирония для тех, кто не умеет воспринимать конструктивную критику со стороны  ;)

Извините за резкость, но в первую очередь нужно включать мозги, а не молиться на стандарт! По главной диагонали легко и просто располагать элементы, если они образуют некую логическую последовательность. Если IDEF0 используется для отображения системы бизнес-процессов верхнего уровня, то все процессы выстроить в последовательность не получится: будет главная диагональ: стратегия, создание продукта, продажи, снабжение и производство. А вспомогательные процессы или, скажем, финансирование деятельности,  в эту диагональ не ложатся, они работают параллельно по отношению к основным процессам, поэтому отображаются сверху/снизу главной диагонали.

Во-первых, предыдущий пост был иронией, о чём я явно снизу указал.

Во-вторых, IDEF0 призывает упорядочивать процессы по принципу доминирования, а не логической последовательности, о которой Вы пишите. Да и ни в этом дело, меня просто повеселила формулировка про то, «чтобы не было "узлов" и "бантиков"».

Вообще-то, в IDEF0 на верхнем уровне удобно в первую очередь отображать взаимодействия между процессами, а не их логическую последовательность, по крайней мере, я так считаю. О том, что нужно выстраивать последовательность выполнения процессов по диагонали, а вспомогательные процессы отображать сверху/снизу слышу впервые. Посмотрите диаграмму А0 в демо базе данных «ИнТехПроект», там вообще диагонали как таковой нет, есть обычные взаимодействия. Кроме того, БС нумерует блоки по принципу «чем правее расположен - тем больше номер» и именно нумерация блоков как раз и отображает эту самую условную последовательность выполнения, никаких «параллельных» выполнений блоков снизу и сверху не предусмотрено.

Но это моё лично мнение, дискутировать на эту тему бессмысленно, программа позволяет располагать блоки как угодно, пускай каждый строит, так, как считает нужным. 

И что тогда есть доминирование, если не некая логическая последовательность?
Не поленился и залез в книгу:
"Блоки SADT никогда не размещаются на диаграмме случайным образом. Они размещаются по степени важности, как ее понимает автор диаграммы. В SADT этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все
другие функции."

Шутки-шутками, а чем меньше "бантиков", тем на самом деле лучше.

И? Вы согласны, что это разумно? Или не согласны, тогда - почему?


Это так. Но и логическую последовательность тоже можно, это повышает понятность системы: видно что за чем следует на макроуровне.
Смотрим на диагрумму Интехпроекта: Сначала стратегия, потом продвижение и продажи (т.е. продали проект), потом планирование проекта, потом закупка под проект.
Воспроизвдоство персонала, инструмента - ниже диагонали, финансирование - выше.

На самом деле обсуждение таких тонкостей полезно, ибо нигде про них не прочитаешь.

Я думаю, что принцип доминирования – это как раз размещение по степени важности. Считаю ли я, что именно так нужно размещать блоки? – Нет, не считаю.

Я замечал, что многих пользователей вообще сбивает нумерация блоков, потому что они пытаются выстроить диаграмму верхнего уровня в порядке выполнения процессов, но это не всегда удаётся.  Тот же блок «воспроизведение персонала», который включает в себя подбор, обучение и увольнение персонала, куда его ставить на схеме? Этот процесс выполняется постоянно на протяжении всей деятельности предприятия. Да, вы поставили его на диаграмме ниже, но он, тем не менее, получает свой порядковый номер «3» и возникает ощущение, этот процесс выполняется после процесса «Продвижение и продажи», который идёт под номером «2». Как выйти из этой ситуации? – Я не знаю,  видимо нужно дополнительно проводить разъяснения по этому поводу с пользователями.

Согласен, что к, сожалению, конкретной практической информации по применению IDEF0 с рассмотрениями таких нюансов нет.

Не обращать внимания на номера процессов на диаграмме верхнего уровня и воспринимать это просто как код процесса.
Но при моделировании стараться располагать блоки, если они образуют логическую последовательность, на главной диагонали. Читать и понимать такие диаграммы потом значительно легче.

Полностью согласен!

Дмитрию.
И исполнителей навесить и шаблоны прикрепить - все делается в разы быстрее и приятнее в BPwin. Единственное чего нельзя сделать - красивый документ. Но и с этой задачей лет 5 назад я уже справлялся. У меня макрос в MS Excel строил документ по выгруженным отчетам ничуть не хуже Бизнес-студии :))

Полностью согласен...В любой программе как и на любом интернет сайте самое главное удобная навигация.Для сайта - это меню,а для любой программы - это кнопки навигации...Самое главное в обоих случаях,чтобы пользователю было как можно комфортней использовать программу,чтобы человек охотно прибегал к её использованию,а не через силу(раз надо-значит придётся работать!).