Расскажете подробнее? Просто я видел (и реализовывал) паттерны с конфигурируемыми полями, но пока не могу понять, как за счет таких полей выстроить реляционные отношения в несколько уровней.
И второй вопрос — почему вы говорите только об админке, на чем вы пишите фронт?
Если говорить о других примерах вложенности, где можно использовать CRUD-виджеты, могу привести из другого моего проекта: пользователь имеет список записей в балансе, каждая запись имеет список счетов, каждый счет имеет список исторических значений (по одному на каждый месяц) и связи на транзакции (дебет/кредит).
Здесь полностью приложение написано на Yii. Админка, конечно, есть, но она скорее утилитарная — справочники настроить, какие-то общие параметры и т.п. Соль как раз в интерфейсах для конечных пользователей для отображения и управления такими вложенными сущностями.
Видимо, я слишком сильно упростил пример. Речь не идет о стандартной CMS, для которой нужна одна админка с набором полей. Речь идет о проекте, когда пишется полноценный кастомный бэк, со сложной моделью данных и бизнес логикой.
Например, в одном из моих гейм-дев проектов есть такая структура: основная сущность — квест, он состоит из этапов. Этапы состоят из сообщений. Сообщения могут содержать мини игру. Мини игры могут быть разных типов, один из них — викторины, которые содержат список вопросов. А к каждому вопросу есть список вариантов ответов с одним правильным.
Если вы можете привести ссылку на готовое решение для такой возможности, буду благодарен.
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
А что если сайт является «спутником» для мобильного приложения, в котором, работает аналитика, показывается реклама и/или есть возможность совершать микротранзакции?
Особенно интересно, как это все связать с новым законом GDPR?
с вашего позволения я процитирую часть своего комментария выше, на который вы, к сожалению, не ответили:
если бизнес-процесс не приносит прибыль, но на него совершаются затраты, то зачем он вообще нужен компании? Если это чисто убыточный процесс, то его можно остановить, и компания окажется в выигрыше, разве нет? Ответ скорее всего в том, что этот процесс «помогает» другим бизнес-процессам, являясь для них составной частью или подпроцессом, а это значит, что в конечном итоге он помогает увеличить прибыль от основного процесса. Именно об этом говорят все известные спикеры, что процесс должен всегда в конечном итоге приносить прибыль.
Метод оценки влияния процесса на прибыль может быть разным, я взял для примера самый простой — сравнение с аутсорсом, предполагая прочие параметры равными. Вы можете взять другой, но важно, чтобы он был.
Можно вместо слова прибыль использовать слово ценность (business-value в англоязычной литературе) при сохранении смысла моего комментария. Но на самом деле, в подавляющем большинстве случаев можно все равно говорить о прибыли.
Например, государственная организация, дотируемый процесс — он должен служить долгосрочной цели, например, поддержки и развития малого бизнеса или увеличению здоровья и продолжительности жизни населения. Оба результата косвенно принесут прибыль государству через увеличение налогов.
В некоммерческих организациях все тоже так или иначе крутится вокруг денег. Да, основной процесс такой организации, может не приносить прибыли напрямую, однако для всех без исключения второстепенных процессов эту прибыль можно посчитать ровно также, как и для коммерческих — как разницу затрат и стоимости аутсорса. Основной же процесс приносит «прибыль» или ценность в виде достижения заявленных целей, что, кстати, в свою очередь определяет уровень пожертвований от инвесторов: чем эффективнее и результативнее процесс, тем больше инвестиций.
И да, я не говорю о процессах, особенно в государственных учреждениях, которые действительно не нужны, а остались, как наследие от прошлых решений, которые никто не отменял (все помнят анекдот про караул в Зимнем саду над подснежниками). Там бесполезно искать и прибыль, и ценность, да и разум с логикой тоже…
Тема полезная, однако есть ряд неточных пунктов в статье, особенно важных с прикладной точки зрения. Привожу их в соответствии с порядком участков текста статьи, к которым они относятся.
Важно, что бизнес-процесс в первую очередь оперирует ролями, а вовсе не людьми: исполнителем роли может быть человек, группа людей или система. Всего лишь один исключительный случай, когда все роли исполняются системами, можно рассматривать отдельно, хотя даже для описания этого процесса удобно использовать те же нотации.
Во-вторых, точку зрения про отсутствие бизнес-процесса без его описания можно сравнить с мнением, что третий закон Ньютона не существовал до его открытия. Возьмите компанию, которая удовлетворяет запросы клиентов, платит зарплату сотрудникам, налоги государству и прибыль владельцу, но не имеет описаний бизнес-процессов в том виде, в котором вы привыкли их видеть. Вы скажете, что в компании нет бизнес-процессов? Не думаю.
Далее, различие между вашими определениями технологического и бизнес процессов содержат противоречия. У бизнес-процесса есть понятие happy path, которое полностью соответствует вашему описанию технологического процесса, как последовательности шагов, ведущих к единственному целевому результату. В то же время в технологическом процессе полно развилок, например в случае брака на определенном этапе, заготовку можно отправить на доработку (цикл) или переработку с последующим использованием в другом качестве (альтернативный путь процесса). В итоге, оба процесса в полной мере обладают качествами, которые вы выделили как дифференцирующие, т.е. нет смысла их разделять. Во всяком случае, не по этому признаку.
Ваш взгляд на историю появления термина достаточно спорный, однако этот вопрос не имеет практической пользы, поэтому предлагаю оставить.
Замечания относительно процесса продажи повторяют ошибку из вводной части статьи, требуя наличия описания процесса для подтверждения факта его существования. Хотя, строго говоря, даже в вашем же определении отсутствует требование об обязательности описания процесса, вы вводите это позднее. В вашем определении, бизнес-процесс — это последовательность действий людей (ролей), приводящая к достижению цели, на этом и надо остановиться.
Несколько опечаток резанули глаза (swimm line и другие), поправьте, пожалуйста.
Наконец, и, пожалуй, одно из самых главных — про бизнес-процессы и прибыль. Здесь все просто: если бизнес-процесс не приносит прибыль, но на него совершаются затраты, то зачем он вообще нужен компании? Если это чисто убыточный процесс, то его можно остановить, и компания окажется в выигрыше, разве нет? Ответ скорее всего в том, что этот процесс «помогает» другим бизнес-процессам, являясь для них составной частью или подпроцессом, а это значит, что в конечном итоге он помогает увеличить прибыль от основного процесса. Именно об этом говорят все известные спикеры, что процесс должен всегда в конечном итоге приносить прибыль.
Как пример, для любого обслуживающего процесса его ценность может быть легко вычислена как разность фактических затрат и стоимости, которую пришлось бы заплатить, отдав его на аутсорс.
В итоге, ещё раз — тема, поднятая вами, полезна, но ряд существенных деталей требуют доработки. Готов раскрыть подробнее любой из моих комментариев, обращайтесь, если нужно.
Вы все правильно пишете, но не даете ответа на вопрос — как определить, что исполнитель провел качественный анализ и результатам его проверок гипотез можно доверять, или он просто слил задачу, а вся статистическая разница определяется сезонной/недельной погрешностью?
Допустим, вы говорите, что на месяц нельзя предсказать, но тогда на какой срок можно? Скажем, средняя стоимость привлеченного клиента за 3 месяца или за 6? Больше уже просто нет смысла оценивать.
Ценность исследований точно также понятна и поддается расчету: можно потратить сейчас на исследование разных стратегий 50 тысяч или 100 тысяч, но зато потом в течение 3 (6?) месяцев эффективность рекламы будет выше, что позволит окупить эти затраты. Или не позволит, но тогда — зачем исследования?
С точки зрения владельца бизнеса, все измеряется в деньгах, которые он заработает от этого бизнеса. Любые изменения в сайте, исследования маркетинговых инструментов, проверка гипотез — все это должно быть обосновано прибылью. Если не в краткосрочной перспективе, то в средне или долгосрочной — в зависимости от сумм затрат и текущего положения компании на рынке.
Реклама — это такой же участок бизнеса, как и логистика, производство или программирование. На всех этапах есть свои риски, гипотезы для проверки и деньги для счета. Поэтому реклама, как и любой другой аспект бизнеса должна иметь свои критерии эффективности, с позиции которых и принимаются решения относительно любых гипотез.
Так вот и вопрос — какие это критерии на ваш взгляд?
Хороший пример, согласен, волатильность спроса присутствует. Но как тогда оценить эффективность работы рекламщика? Как сказать, что вот этот специалист лучше того, на основе какого критерия?
В том-то и дело, что владельцу бизнеса нужен не трафик на сайт, а продажи. А уже способность увеличить продажи за счет улучшения качества трафика вызовет у владельца бизнеса больше доверия к специалисту и является обязательным условием для начала обсуждения любых других изменений в сайте/сервисе, естественно через АБ-тестирование. Кто будет выполнять эти изменения — уже совершенно другой вопрос.
Возвращаясь к исходному вопросу, вынесенному в заголовок статьи: почему все-таки специалисты по продвижению не готовы гарантировать продажи при условии сохранения остальных аспектов?
Вы меня не услышали.
Суть любых АБ-тестов в том, что в каждый момент времени меняется только один параметр — либо сайт (или даже какой-то один аспект сайта), либо источники трафика. Когда владелец бизнеса приходит к специалисту по продвижению, он хочет поменять только источник трафика. Может быть, он пришел одновременно к нескольким специалистам и собирается замерять их сравнительную эффективность — чей трафик будет лучше при прочих равных условиях.
Можно сколько угодно улучшать сайт, сервис и продажи, но вопрос в другом: они сейчас уже работают с определенной известной эффективностью.
Если при изменении только источника трафика общая эффективность упадет, это значит, что проблема не в сайте, сервисе или продажах. Проблема — в источнике трафика. Разве нет?
Почему интернет-продвижение не может гарантировать N продаж в месяц?
Вот и правда — почему? Положим, есть простой лендинг по продаже мелкой бытовой техники с формой заказа и оплаты. Есть настроенная кампания в директе, есть текущие показатели конверсии и рекламного бюджета. Для заказчика в такой ситуации вполне логично ожидать, что специалист по продвижению даст ему увеличение продаж, иначе зачем этот специалист вообще нужен?
Утверждение, что интернет-продвижение должно просто приводить посетителей на сайт — не верно: задача продвижения — приводить посетителей, которые совершат покупку и никак иначе. А то можно повесить порно-баннер — переходов будет тьма, а вот покупок — ноль.
Главный вопрос — по какому показателю мерять эффективность работы специалиста по продвижению? По количеству посетителей — бизнесу не это нужно, а за продажи они отвечать не хотят.
КОП не продвинутое ООП, а надстройка над ним. Согласен с вами по сути изложенного, но не согласен по форме: нельзя противопоставлять ООП и КОП, иначе, прочитав вашу статью, может сложиться впечатление, что ООП — устаревшее зло без права на всплытие.
В вашем примере, кстати, компоненты, отвечающие за урон ближнего боя и урон дальнего боя, вполне логично пронаследовать от одного компонента, отвечающего за урон в принципе.
Согласен, что не нужно пытаться использовать ООП для объектов игрового мира, т.к. они заведомо собираются из различных компонент (начиная от transform и rigitbody, заканчивая контроллерами баффов и собственных действий), но его можно и нужно использовать для реализации аспектов, действительно связанных отношениями родитель-потомок.
Не могу сказать, что современные BRMS и BPMS движутся в сторону Prolog-а, это было бы некорректным утверждением.
Но если говорить о декларативных вычислениях в целом, то в IBM пока такой возможности нет, там все еще доминирует процедурный образ мышления (нынче модно это называть SOA-архитектурой).
Насколько я знаю, в Appian также нет такой возможности, но с этим продуктом я близко не знаком, так что могу ошибаться.
Зато такая возможность есть и активно используется в Pega: там несколько различных типов декларативных правил, самым простым из них является declare expression, задающий формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком Pega (PRPC) одним из двух вариантов:
Пересчитывать результат при каждом изменении любой переменной, входящей в формулу;
Пересчитывать результат при каждом чтении значения рассчитываемой переменной.
При этом, декларативные правила используются именно как дополнение к основному процессу. Это инструмент, который можно применять там, где он эффективен.
Вы правы, на нашем рынке пока очень мало людей, которые действительно знают, как применять BPM-системы. Но опыт американского и европейского рынков подсказывает, что мы тоже к этому придем.
На мой взгляд, из собственного опыта, залог успеха кроется в нескольких простых пунктах, практически независимых от выбранной платформы:
Знать свою платформу: очень часто в реальных проектах на платформах реализуется то, что итак есть, но чуть-чуть по-другому (другой пользовательский портал, своя система уведомлений и т.п.).
Еще раз — знать свою платформу: не менее часто в реальных проектах на таких платформах пытаются реализовать что-то, для чего они не предназначены (как правило — всякие учетные системы).
Ставить бизнес-цели: если проект делается для того, чтобы «потратить бюджет», то вряд ли он будет успешным, какая бы хорошая платформа ни была выбрана. В противовес этому, если проект делается с пониманием, что его внедрение позволит компании сэкономить 5-10 миллионов рублей ежемесячно, тогда у людей появляется стимул принимать нужные решения.
Вовлекать бизнес-пользователей в процесс разработки: еще одна частая проблема в том, что в больших проектах расстояние от бизнес-заказчика до программиста измеряется парой десятков руководителей, аналитиков с обеих сторон, архитекторов, прочих сочувствующих и мегабайтами документов. В результате делается не то, что нужно.
Приведенные скриншоты сняты с IBM ODM. Соглашусь, что это хорошая BR-система, но нельзя сказать, что самая лучшая.
Если вы занимались CRM системами, то вам стоит обратить внимание не только на BRMS, но и на BPMS (Business Process Management System). Посмотрите, например, отчет Gartner BPM Magic Quadrant за 2014 год (можно скачать с сайта IBM, оставив им контактные данные, есть отдельно сравнительная диаграмма из статьи или можно еще погуглить)
Даже если просто взять за основу их сравнительную диаграмму и посмотреть информацию по тройке лидеров (Pegasystems, Appian, IBM BPM), то уже можно составить базовое представление об области.
Для этого размер ортогональной камеры (параметр Size) должен равняться половине высоты экрана в пикселях. Например, если это экран iPhone 3G в портретном режиме, разрешение экрана которого 320x480, то Size = h/2 = 480/2 = 240.
Это некорректно. OrthographicSize камеры должен быть равен половине высоты экрана не в пикселях, а в unit-ах (внутренней единице измерения, обычно приравниваемой к 1му метру).
Понятно, что в целом, описываемый в данной статье подход уже не применим, но этот нюанс с камерой остается актуальным, и он попортил мне довольно много крови.
И второй вопрос — почему вы говорите только об админке, на чем вы пишите фронт?
Если говорить о других примерах вложенности, где можно использовать CRUD-виджеты, могу привести из другого моего проекта: пользователь имеет список записей в балансе, каждая запись имеет список счетов, каждый счет имеет список исторических значений (по одному на каждый месяц) и связи на транзакции (дебет/кредит).
Здесь полностью приложение написано на Yii. Админка, конечно, есть, но она скорее утилитарная — справочники настроить, какие-то общие параметры и т.п. Соль как раз в интерфейсах для конечных пользователей для отображения и управления такими вложенными сущностями.
Видимо, я слишком сильно упростил пример. Речь не идет о стандартной CMS, для которой нужна одна админка с набором полей. Речь идет о проекте, когда пишется полноценный кастомный бэк, со сложной моделью данных и бизнес логикой.
Например, в одном из моих гейм-дев проектов есть такая структура: основная сущность — квест, он состоит из этапов. Этапы состоят из сообщений. Сообщения могут содержать мини игру. Мини игры могут быть разных типов, один из них — викторины, которые содержат список вопросов. А к каждому вопросу есть список вариантов ответов с одним правильным.
Если вы можете привести ссылку на готовое решение для такой возможности, буду благодарен.
Думаю как раз потому, что "дальше его проблемы". Любая автоматизация должна решать проблемы, а не создавать их.
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
Особенно интересно, как это все связать с новым законом GDPR?
Метод оценки влияния процесса на прибыль может быть разным, я взял для примера самый простой — сравнение с аутсорсом, предполагая прочие параметры равными. Вы можете взять другой, но важно, чтобы он был.
Например, государственная организация, дотируемый процесс — он должен служить долгосрочной цели, например, поддержки и развития малого бизнеса или увеличению здоровья и продолжительности жизни населения. Оба результата косвенно принесут прибыль государству через увеличение налогов.
В некоммерческих организациях все тоже так или иначе крутится вокруг денег. Да, основной процесс такой организации, может не приносить прибыли напрямую, однако для всех без исключения второстепенных процессов эту прибыль можно посчитать ровно также, как и для коммерческих — как разницу затрат и стоимости аутсорса. Основной же процесс приносит «прибыль» или ценность в виде достижения заявленных целей, что, кстати, в свою очередь определяет уровень пожертвований от инвесторов: чем эффективнее и результативнее процесс, тем больше инвестиций.
И да, я не говорю о процессах, особенно в государственных учреждениях, которые действительно не нужны, а остались, как наследие от прошлых решений, которые никто не отменял (все помнят анекдот про караул в Зимнем саду над подснежниками). Там бесполезно искать и прибыль, и ценность, да и разум с логикой тоже…
Тема полезная, однако есть ряд неточных пунктов в статье, особенно важных с прикладной точки зрения. Привожу их в соответствии с порядком участков текста статьи, к которым они относятся.
Во-первых, зачем вводить свое определение бизнес-процесса? Если надо на русском, то чем не угодило хотя бы описанное в википедии?
https://ru.wikipedia.org/wiki/Бизнес-процесс
Важно, что бизнес-процесс в первую очередь оперирует ролями, а вовсе не людьми: исполнителем роли может быть человек, группа людей или система. Всего лишь один исключительный случай, когда все роли исполняются системами, можно рассматривать отдельно, хотя даже для описания этого процесса удобно использовать те же нотации.
Во-вторых, точку зрения про отсутствие бизнес-процесса без его описания можно сравнить с мнением, что третий закон Ньютона не существовал до его открытия. Возьмите компанию, которая удовлетворяет запросы клиентов, платит зарплату сотрудникам, налоги государству и прибыль владельцу, но не имеет описаний бизнес-процессов в том виде, в котором вы привыкли их видеть. Вы скажете, что в компании нет бизнес-процессов? Не думаю.
Далее, различие между вашими определениями технологического и бизнес процессов содержат противоречия. У бизнес-процесса есть понятие happy path, которое полностью соответствует вашему описанию технологического процесса, как последовательности шагов, ведущих к единственному целевому результату. В то же время в технологическом процессе полно развилок, например в случае брака на определенном этапе, заготовку можно отправить на доработку (цикл) или переработку с последующим использованием в другом качестве (альтернативный путь процесса). В итоге, оба процесса в полной мере обладают качествами, которые вы выделили как дифференцирующие, т.е. нет смысла их разделять. Во всяком случае, не по этому признаку.
Ваш взгляд на историю появления термина достаточно спорный, однако этот вопрос не имеет практической пользы, поэтому предлагаю оставить.
Замечания относительно процесса продажи повторяют ошибку из вводной части статьи, требуя наличия описания процесса для подтверждения факта его существования. Хотя, строго говоря, даже в вашем же определении отсутствует требование об обязательности описания процесса, вы вводите это позднее. В вашем определении, бизнес-процесс — это последовательность действий людей (ролей), приводящая к достижению цели, на этом и надо остановиться.
Несколько опечаток резанули глаза (swimm line и другие), поправьте, пожалуйста.
Наконец, и, пожалуй, одно из самых главных — про бизнес-процессы и прибыль. Здесь все просто: если бизнес-процесс не приносит прибыль, но на него совершаются затраты, то зачем он вообще нужен компании? Если это чисто убыточный процесс, то его можно остановить, и компания окажется в выигрыше, разве нет? Ответ скорее всего в том, что этот процесс «помогает» другим бизнес-процессам, являясь для них составной частью или подпроцессом, а это значит, что в конечном итоге он помогает увеличить прибыль от основного процесса. Именно об этом говорят все известные спикеры, что процесс должен всегда в конечном итоге приносить прибыль.
Как пример, для любого обслуживающего процесса его ценность может быть легко вычислена как разность фактических затрат и стоимости, которую пришлось бы заплатить, отдав его на аутсорс.
В итоге, ещё раз — тема, поднятая вами, полезна, но ряд существенных деталей требуют доработки. Готов раскрыть подробнее любой из моих комментариев, обращайтесь, если нужно.
Допустим, вы говорите, что на месяц нельзя предсказать, но тогда на какой срок можно? Скажем, средняя стоимость привлеченного клиента за 3 месяца или за 6? Больше уже просто нет смысла оценивать.
Ценность исследований точно также понятна и поддается расчету: можно потратить сейчас на исследование разных стратегий 50 тысяч или 100 тысяч, но зато потом в течение 3 (6?) месяцев эффективность рекламы будет выше, что позволит окупить эти затраты. Или не позволит, но тогда — зачем исследования?
С точки зрения владельца бизнеса, все измеряется в деньгах, которые он заработает от этого бизнеса. Любые изменения в сайте, исследования маркетинговых инструментов, проверка гипотез — все это должно быть обосновано прибылью. Если не в краткосрочной перспективе, то в средне или долгосрочной — в зависимости от сумм затрат и текущего положения компании на рынке.
Реклама — это такой же участок бизнеса, как и логистика, производство или программирование. На всех этапах есть свои риски, гипотезы для проверки и деньги для счета. Поэтому реклама, как и любой другой аспект бизнеса должна иметь свои критерии эффективности, с позиции которых и принимаются решения относительно любых гипотез.
Так вот и вопрос — какие это критерии на ваш взгляд?
Возвращаясь к исходному вопросу, вынесенному в заголовок статьи: почему все-таки специалисты по продвижению не готовы гарантировать продажи при условии сохранения остальных аспектов?
Суть любых АБ-тестов в том, что в каждый момент времени меняется только один параметр — либо сайт (или даже какой-то один аспект сайта), либо источники трафика. Когда владелец бизнеса приходит к специалисту по продвижению, он хочет поменять только источник трафика. Может быть, он пришел одновременно к нескольким специалистам и собирается замерять их сравнительную эффективность — чей трафик будет лучше при прочих равных условиях.
Можно сколько угодно улучшать сайт, сервис и продажи, но вопрос в другом: они сейчас уже работают с определенной известной эффективностью.
Если при изменении только источника трафика общая эффективность упадет, это значит, что проблема не в сайте, сервисе или продажах. Проблема — в источнике трафика. Разве нет?
Вот и правда — почему? Положим, есть простой лендинг по продаже мелкой бытовой техники с формой заказа и оплаты. Есть настроенная кампания в директе, есть текущие показатели конверсии и рекламного бюджета. Для заказчика в такой ситуации вполне логично ожидать, что специалист по продвижению даст ему увеличение продаж, иначе зачем этот специалист вообще нужен?
Утверждение, что интернет-продвижение должно просто приводить посетителей на сайт — не верно: задача продвижения — приводить посетителей, которые совершат покупку и никак иначе. А то можно повесить порно-баннер — переходов будет тьма, а вот покупок — ноль.
Главный вопрос — по какому показателю мерять эффективность работы специалиста по продвижению? По количеству посетителей — бизнесу не это нужно, а за продажи они отвечать не хотят.
В вашем примере, кстати, компоненты, отвечающие за урон ближнего боя и урон дальнего боя, вполне логично пронаследовать от одного компонента, отвечающего за урон в принципе.
Согласен, что не нужно пытаться использовать ООП для объектов игрового мира, т.к. они заведомо собираются из различных компонент (начиная от transform и rigitbody, заканчивая контроллерами баффов и собственных действий), но его можно и нужно использовать для реализации аспектов, действительно связанных отношениями родитель-потомок.
Но если говорить о декларативных вычислениях в целом, то в IBM пока такой возможности нет, там все еще доминирует процедурный образ мышления (нынче модно это называть SOA-архитектурой).
Насколько я знаю, в Appian также нет такой возможности, но с этим продуктом я близко не знаком, так что могу ошибаться.
Зато такая возможность есть и активно используется в Pega: там несколько различных типов декларативных правил, самым простым из них является declare expression, задающий формулу для вычисления значения переменной. Исполнение этой формулы обеспечивается движком Pega (PRPC) одним из двух вариантов:
При этом, декларативные правила используются именно как дополнение к основному процессу. Это инструмент, который можно применять там, где он эффективен.
На мой взгляд, из собственного опыта, залог успеха кроется в нескольких простых пунктах, практически независимых от выбранной платформы:
Если вы занимались CRM системами, то вам стоит обратить внимание не только на BRMS, но и на BPMS (Business Process Management System). Посмотрите, например, отчет Gartner BPM Magic Quadrant за 2014 год (можно скачать с сайта IBM, оставив им контактные данные, есть отдельно сравнительная диаграмма из статьи или можно еще погуглить)
Даже если просто взять за основу их сравнительную диаграмму и посмотреть информацию по тройке лидеров (Pegasystems, Appian, IBM BPM), то уже можно составить базовое представление об области.
Это некорректно. OrthographicSize камеры должен быть равен половине высоты экрана не в пикселях, а в unit-ах (внутренней единице измерения, обычно приравниваемой к 1му метру).
Понятно, что в целом, описываемый в данной статье подход уже не применим, но этот нюанс с камерой остается актуальным, и он попортил мне довольно много крови.