Опрос: Как вы учитываете изменения в бизнес-процессах

← →
Ega23 © (2011-02-03 16:58) [40]

> Юрий Зотов © (03.02.11 16:38) [33]

во, мы тоже подобную схему реализовывали.

← →
12 © (2011-02-03 17:06) [41]

> Ega23 © (03.02.11 16:58) [40]

и реализовали?

← →
Ega23 © (2011-02-03 17:17) [42]

> и реализовали?

Ага. Сейчас, правда, без содрогания не вспомнить. Как начальник сказал: "- Система приобретает вид лома с кучей конфигурируемых шарниров."
Но реальные инсталляции ещё при мне были (как раз когда по Дагестану мотался), потом ребята допилили до приемлемого уровня.

← →
Empleado © (2011-02-03 17:19) [43]

> Как вы учитываете изменения в бизнес-процессах

Из опыта:

Таблица с факторами влияющими на ценообразование.
В программе уже заложена функциональность, обеспечивающая учет уже существующих факторов, а также есть параметр(ы) для вкрапления новых, еще не присутствующих в таблице факторов.
Изменять/создавать факторы имеют право только Advanced Users нашего приложения.
(Схема работает 10 лет. Поставщики обновляют каталоги 1-2 раза в год, соответственно параметры меняются минимум 1-2 раза в год, иногда пользователи меняют 8-10 раз некоторые параметры некоторых совокупностей данных некоторых каталогов)

← →
12 © (2011-02-03 17:28) [44]

> Ega23 © (03.02.11 17:17) [42]

везет :)
ни разу не видел такую систему
1С, которую не предлагать :), тоже стала требовать программиста довольно скоро..

> Ega23 © (03.02.11 16:55) [38]
> для, например, MSSQL - общая длина поля, связано с тем,
> что первичный ключ кластерным индексом является

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

← →
DiamondShark © (2011-02-03 17:44) [45]

> это по умолчанию и по прямости рук так должно быть

По умолчанию -- да. А вот с прямостью...
Представьте, что у вас превичный ключ -- какая-то хрень, которая не является монотонно возрастающей в порядке добавления. Например, GUID

Кластерный индекс по GUIDу -- это ад и израиль.

← →
Юрий Зотов © (2011-02-03 17:45) [46]

> 12 © (03.02.11 16:54) [37]
> а реально, они сами, средней сложности логику, строят?

Строят, но не все. Те, кто не умеет (а скорее - не хочет) делать это сам, обращаются к разработчикам. Ну а пощелкать мышкой 5 минут за бабки клиента - что может быть приятнее?

← →
Ega23 © (2011-02-03 17:49) [47]

> кстати, необязательно первичный ключ кластерным индексом
> является

Вот я специально именно MSSQL в пример привёл. Там - является. А вторичный - не является индексом, только кандидатом на индекс.

> Кластерный индекс по GUIDу -- это ад и израиль.

Не, для GUID - ничего страшного, 16 байт.

← →
Дмитрий Тимохов (2011-02-03 18:01) [48]

Мы программу правим.
Все история остается в SVN.

← →
boriskb © (2011-02-03 18:05) [49]

> Интересна именно практика, какие решения вами (вашими знакомыми/незнакомыми)
> использовались в проектах

Сильно уж зависит от предметной области.

Пытался улавливать "структуры" и их формализовать.
Ну не совсем же уж от фоноря они новые расчетные схемы придумывают.
Всё равно в каких-то рамках. Вот эти рамки и искал. Вместе с заказчиком естественно.
А дальше, никуда не денешься - "метаязык", но он совсем не сложный становится, если удаётся правильно уловить/установить рамки

← →
DiamondShark © (2011-02-03 19:05) [50]

> Ega23 © (03.02.11 17:49) [47]

Первичный ключ кластерный если явно не указано NONCLUSTERED и нет других кластерных ключей и индексов.
Но может быть некластерным при явном указании.

Кластерный индекс по GUID страшен не размером, а порядком сортировки.

← →
Ega23 © (2011-02-03 19:42) [51]

> Но может быть некластерным при явном указании.

Да? Ну фиг знает, может и так. BOL под рукой нет, да и с сиквелом уже давно дела не имел. Возможно, спорить не буду.

> Кластерный индекс по GUID страшен не размером, а порядком
> сортировки.

А тебе не всё равно, в каком оно порядке индексируется "где-то-там-в-недрах"?
Мне сложно представить, когда нужно сортировать по GUID-у.
Впрочем, точно также сложно представить, когда надо по первичному (физическому) ключу сортировать. Обычно по названию, ну там дате, ещё какой-нибудь фигне. Я в справочных таблицах частенько int-поле сортировки закладывал, чтобы пользователь сам мог настроить порядок вывода записей. Например, те, которые чаще всего используются - в начале выборки.

Хотя, если честно, я всего 1 раз GUID первичным ключом делал. Но там действительно без этого было бы крайне тяжко, ибо нет в MSSQL сиквенсов.

← →
DiamondShark © (2011-02-03 20:20) [52]

> Ega23 © (03.02.11 19:42) [51]

При хранении и выборках пофиг. Но:

> The pages in the data chain and the rows in them are ordered
> on the value of the clustered index key. All inserts are
> made at the point where the key value in the inserted row
> fits in the ordering sequence among existing rows.

Улавливаешь, что будет происходить при вставках хаотических значений ключа кластерного индекса?

← →
MsGuns © (2011-02-03 20:24) [53]

>DiamondShark © (03.02.11 16:56) [39]
>> С ростом библиотеки шагов программист становится нужен все меньше и меньше.
>А кликающий настройщик плавно превращается в программиста на вновь >зародившемся DSL. И круг повторяется.

Верно подмечено :)

← →
MsGuns © (2011-02-03 20:37) [54]

Из собственного опыта:

Всего существует не так уж много путей "универсализации".

Путь 1. "Купить готовое"
Навроде упомянутой здесь действительно мощной системы типа SAP-R3
Но помимо денюх, мороки с настройкой и т.д. нет никакой гарантии, что
А) Все проблемы реально решатся, а не перейдут на новый уровень
Б) Внедрение и сопровождение не потянет за собой куда большие затраты, чем замененная "ручная", к тому же усугубится пресловутой кадровой проблемой
В) Вообще система "натянется" на реальные условия

Путь 2. "Заказать готовое"
В какой-то мере общится с 1), но иногда реально помогает.
Минусы тоже очевидны - не имеет смысла перечислять.

Путь 3. "Придумать свое"
В принципе самый "правильный" способ хотя бы потому, что все в твоих руках. Однако чтобы заниматься подобными на сложных ОА (объектах автоматизации), надо иметь достаточно хорошие гарантии со стороны работодателя: как в финансовом, так и во временном отношении.
К тому же самый рИсковый путь, где гарантия, что ГИПу не осточертеет бороться с постоянно возникающими проблемами, что у него хватит мозгов, что его коллег хватит мозгов, что хватит мозгов у руководства все это терпеть и т.д.

И все-таки, ИМХО, путь 3 самый интересный (для меня во всяком случае :)
И если итти все же им, то надо сразу определиться с базовыми вещами (самое трудное) - КТО будет пользоваться системой, ЗАЧЕМ и ЧЕМ готов пожертвовать.

← →
MsGuns © (2011-02-03 20:43) [55]

Мне доводилось работать на всех 3-уровнях (уровень монстра типа САП-Р3,- "Парус" в большой корпорации, прохожу в настоящее время Э<8:o).
Каждый по-своему интересен и полезен. Все зависит опять же от предметной области и объекта автоматизации.

> Ega23 © (03.02.11 19:42) [51]

такое может еще случится, когда сменили PK и вообще стали явно колдовать над индексами, "повышая производительность"
Вот потом точно - ад и израиль :)

← →
Константинов (2011-02-06 01:39) [57]

И все-таки я не до конца понял что имеется ввиду. Построение математической модели бизнес-процесса? Или обработка конкретной информации (например финансовой) из конкретных БД, для последующего анализа менеджером?

Если первое, то я поступал так (не как программист, а как "аналитик"):
а) определял какие факторы значимы для бизнес-процесса (на первом этапе это можно сделать грубо)
б) считал динамику изменений каждого фактора на протяжении достаточно длительного периода
в) смотрел динамику действий конкурентов на данном направлении
г) Складывал полученные значения, получая грубую бизнес-модель.
Если не вписывался в расчетные значения прибыли начинал модель "дотачивать напильником", желая получить приемлемые цифры.

Если второе (и речь идет об оптимизации существующего бизнес-процесса)
на мой взгляд в программе нужно учитывать только те факторы, которые поддаются учету (уже учтены) и она должна уметь делать выборки из существующих БД.
Тут много засад. Бизнес-процесс всегда сильно зависит от внешних факторов (действия конкурентов, колебания курсов валют, текучки кадров и т.п.)
поэтому выборки из БД дают лишь часть необходимой информации для принятия решений... очень многие факторы влияют на результат не явно или имеют разный эффект на разных по продолжительности отрезках времени. пример: оператор связи, эксплуатируется сеть. Операционные затраты ххх руб. 30% от затрат - ФОТ персонала.
В краткосрочной перспективе, ФОТ можно соптимизировать до 0% и результат (количество проданного трафика почти не изменится), в долгосрочной перспективе, когда потребуется серьезный апгрейд сети или когда конкуренты начну массово внедрять доп. услуги - эта статья затрат станет критичной. Доходы начнут снижаться прямо пропорционально "неудовлетворенности" пользователей предоставляемыми услугами. Как посчитать эту "неудовлетворенность"? Никак. Можно только оценить по косвенным признакам (количество расторгнутых договоров).... Значимый фактор остается за бортом мат. модели бизнес-процесса.

вычислить, как наиболее эффективно построить бизнес-процесс, это даже не наука, это талант, который дан далеко не каждому менеджеру.

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

Константинов (06.02.11 01:39) [57]

> И все-таки я не до конца понял что имеется ввиду

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

← →
Mike_Goblin (2011-02-07 14:38) [59]

Добрый день, Игорь

Прочитал ветку, сложилось впечатление, что ты ищешь либо решения из области BPM (Business process management), либо из смежной с ней области Rule based engine.

В любом случае, посмотри на Drools http://www.jboss.org/drools.
Не интегрируешь с Delphi, так обогатишься идеями.

Если предлагаемое направление раздумий ведет совсем не туда, попробуй еще раз уточнить или переформулировать требования.

Mike_Goblin (07.02.11 14:38) [59]

Добрый день, Михаил,

Скорее из области Rule based engine. За ссылку спасибо, для интеграции с существующими приложениями на первый взгляд слишком мощно :)

← →
b z (2011-02-07 17:05) [61]

> И все-таки я не до конца понял что имеется ввиду.
Ну тогда в N-ий раз расскажите свою историю, может ктото и "клюнет"...

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

Опрос: Как вы учитываете изменения в бизнес-процессах Найти похожие ветки