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

← →
Игорь Шевченко © (2011-02-03 10:40) [0]

Советуюсь с миром, как лучше учитывать изменения в бизнес-процессах, с наименьшими затратами на программирование.

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

Интересует как удачный/неудачный опыт сообщества, так и мнение сообщества об оптимальных путях решения.

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

1С не предлагать :)

← →
KilkennyCat © (2011-02-03 11:20) [1]

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

← →
oxffff © (2011-02-03 11:24) [2]

Посмотреть на SAP R3.
В документе R3 есть вкладака "условия" с так называемыми условиями(виды промежуточных сумм из которых формируется итоговая сумма).
Человек настраивает алгоритм расчета оперируя условиями и связями между ними.
Я к сожалению не знаю как это делается. Но вроде удобно.
Понятное дело, что это некая таблица связок между условиями при изменении которых вызываются например callback других условий и т.д.
То есть расчет выпрямляется на набор условий которые вычисляются последовательно для получения итоговой суммы.
+ естественно проход по условиям управляется состоянием этих условий.

← →
И. Павел © (2011-02-03 11:27) [3]

> Посмотреть на SAP R3.

Начать просмотр рекомендую с цены :)
Я SAP почти не занимаюсь, но у нас поддержкой одного только HR занимаются 5 программистов, так что это, видимо, тоже не панацея.

← →
oxffff © (2011-02-03 11:45) [4]

> но у нас поддержкой одного только HR занимаются 5 программистов,

+проектный офис + 3 уровня обработки заявки пока дойдет до программистов. Отсюда и цена + отстегивание в SAP ежегодное за user license.

← →
oxffff © (2011-02-03 11:46) [5]

У нас HR, MM, FI, SD, TORO.

← →
Ega23 © (2011-02-03 11:46) [6]

> Начать просмотр рекомендую с цены :)

Ты пост-то прочитал, или нет? Или знакомое слово увидел - и как обычно в бой?

← →
Ega23 © (2011-02-03 11:47) [7]

> Отсюда и цена + отстегивание в SAP ежегодное за user license.

Цена там из-за ничем не обозначенной зарплаты консультантов и абаперов.

← →
И. Павел © (2011-02-03 11:51) [8]

> [6] Ega23 © (03.02.11 11:46)

А вам, похоже, для того чтобы начать флудить и знакомого словаачала не нужно...
Я сказал, что SAP не панацея по гибкости, позволяющая обойтись пользователям без программистов при изменении требований.

Что вам опять не по нраву? Поясните.

← →
12 © (2011-02-03 11:54) [9]

SAP, сап.. панацея что ли?
Мне бывший начальник один сказал - Внедряем SAP. На вопрос примерно такой: "нахрена " ответил примерно так: "Нада".
На самом деле, думаю, Генеральный узнал, что с внедренным SAP контора будет стоит дороже..
(Тип менеджера №1 из спича Константинова)
И не поспоришь же - как минимум на лицензию SAP :)

по сабжу - если б не ИШ был топик-стартером,
сказал бы что процедуры. Выделить и переписывать, по заказу/требованиям.
Так и делаю и делали до этого и пока SAP внедряли тоже так делали. А после я ушел, но подозреваю, что или еще народу больше стало, теперь SAP настраивают, или продолжают процедурки переписывать.
Но, так как ИШ, не скажу :)

← →
oxffff © (2011-02-03 11:56) [10]

> Генеральный узнал, что с внедренным SAP контора будет стоит
> дороже..

Это единственный плюс SAP.

← →
Sergey Masloff (2011-02-03 11:59) [11]

12 © (03.02.11 11:54) [9]
Ну а если историчность нужно сохранить? И на любой момент рассчитывать по правилам действующим на тот момент? А правила меняются раз в 2-3 месяца? А системе уже 15 лет
Подумай что за процедуры там будут
;-)

← →
Jeer © (2011-02-03 12:02) [12]

Для OLAP и DataMining наличие метаязыка практически стандарт.
Поскольку я вплотную и долго занимаюсь OLAP для систем принятия решений, такой метаязык был введен в мои системы ( основан на одном из паскалевских скриптов).

В качестве примера таких систем (примерные аналоги моих систем):
http://www.prognoz.ru/ru/index.php
http://www.keysystems.ru/
http://infovisor.ivanovo.ru/
http://www.bars-open.ru/articles

← →
Ega23 © (2011-02-03 12:05) [13]

> Я сказал, что SAP не панацея по гибкости, позволяющая обойтись
> пользователям без программистов при изменении требований.

Ты сказал, что начинать надо с просмотра цены. И что поддержкой HR-модуля у вас 5 быдлокодеров занимаются.
Я не хочу никого обидеть, но 99,9% российских "специалистов"-сапёров являются быдлокодерами. Которые прослушали полугодичные курсы, более-менее знают структуру таблиц, умеют говорить умные слова "Это проблема в Базисе" и претендуют на зарплату от 100.000. Вот дословно вчерашний вопрос одно сапера (довольно толкового, между прочим):
Слушай, гуру, а вот скажи мне - что более правильно 1. Сделать ключ из 11 числовых полей по 10 знаков, из которых некоторые могут быть нолями 2. Склеить эти 11 полей в одно строковое и сделать по нему ключ Это чисто для интереса. У нас тут народ до меня реализовал пункт 2. Я вот пытаюсь понять - для чего так сделано:-(...

И такая хрень у них там - повсеместно.
Так что то, что у вас 5 человек этим занимается - это абсолютно ни о чём не говорит.

А Сергей рекомендовал Игорю саму идею, а не сам САП.

← →
И. Павел © (2011-02-03 12:11) [14]

> [13] Ega23 © (03.02.11 12:05)

Артемий Лебедев скромко стоит в сторонке...

← →
Ega23 © (2011-02-03 12:22) [15]

> Артемий Лебедев скромко стоит в сторонке...

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

← →
oxffff © (2011-02-03 12:41) [16]

> Ega23 © (03.02.11 12:22) [15]

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

Приезжал на курсы SAP Enjoy Controls рассказывали как создавать объекты, вызывать методы, устанавливать свойства.
Запомнилось только постоянные чаепития во время обучения. И это не только в SAP. Видимо вообще западная технология купить клиента недорого, чтобы сосать из него бабло.

Что касаемо специалистов. Меня раздражают 3 уровня между программистами и заказчиками. Постоянные селекторы и всякая другая шляпа выкручивают мозг. У нас в кабинете сидит специалист по HR.
Хочется дать иногда пендаля всему HR. И сказать может вы ребята прекратите заниматься ... и обсуждать умными словами очень простую бизнес логику.
Порой думаешь им походу самим нравиться выпячивать свое Я за счет непонятных другим словечек. Расчет зарплаты и выплат настраивают постоянно. Постоянные звонки над ухом. И трындешь.
И постоянно вылезают грабли. А бизнес логика проробатывалась 3 уровнями до внедрения. А почему тогда не работает? :)

Вот такое мое мнение.

P.S.
Мы сами больше по FI, SD, MM и взаимодействию SAP с внешними системами.
+ все остальное что не связано с SAP.

← →
oxffff © (2011-02-03 12:43) [17]

> Стараюсь писать сложно, очень сложно,

На самом деле стараюсь писать обобщенно с просмотром на несколько шагов вперед. Поскольку приходилось переписывать логику прописанную в коде. Стараюсь писать металогику, которая настраивается вне программы.

← →
oxffff © (2011-02-03 12:48) [18]

Теперь насчет программистов для SAP. Я думаю, что хороших программистов мало. Впрочем как и не только для SAP.

← →
Ega23 © (2011-02-03 12:48) [19]

> ABAP изучал сам по книжке, методом тыка, проб и ошибок.

Так у тебя был опыт нормального программирования и проектирования на другом языке. Принципы-то никуда не делись.
А у большинства до этих курсов - ну на VBA пяток-другой макросов под Excel написано. И несколько формочек в Access. И понтов после курсов - выше крыши.

← →
oxffff © (2011-02-03 12:50) [20]

> И понтов после курсов - выше крыши.

Все умрут и они тоже. :)

← →
clickmaker © (2011-02-03 13:18) [21]

когда-то участвовал в разработке средней сложности erp для завода, так там и то не обошлось без примитивного метаязыка. Состоящего из набора действий, условий (отдаленно напоминающего сиквельный job) и простенького интерпретатора паскаль-подобного скрипта

← →
Игорь Шевченко © (2011-02-03 13:22) [22]

Я наверное не так акценты расставил: то, что в SAP или аналогичных системах есть свои языки для описания бизнес-процессов это не то, что интересно. Интересна именно практика, какие решения вами (вашими знакомыми/незнакомыми) использовались в проектах или планируется использовать или использовали, но неудачно :)

← →
b z (2011-02-03 13:34) [23]

У нас расчеты простецкие, поэтому не заморачиваясь прикрутили яваскрипт. Хранится в базе, считает либо на клиенте либо в прям базе, зависит как и откуда данные приходят.

← →
DiamondShark © (2011-02-03 13:45) [24]

> Игорь Шевченко © (03.02.11 13:22) [22]

Мы использовали всё: и просто детальные настройки, и сменные хранимки, и прикручивание скрипт-движков, и DSL, и визуальный дизайнер процессов.
Всё кончалось одинаково: нанимался кто-то, кто бы расставлял галки в настройках, допиливал хранимки, писал скрипты, описывал бизнес-логику в DSL или рисовал в дизайнере. Чуть менее, чем всегда, этим кем-то оказывалась наша же контора.
С тех пор идея "Клиент будет настраивать своё бизнес-приложение" однозначно относится к области утопий.

← →
euru © (2011-02-03 14:43) [25]

> Ega23 © (03.02.11 12:05) [13]

> что более правильно
> 1. Сделать ключ из 11 числовых полей по 10 знаков, из которых некоторые могут быть нолями
> 2. Склеить эти 11 полей в одно строковое и сделать по нему ключ

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

← →
euru © (2011-02-03 14:49) [26]

> oxffff © (03.02.11 12:41) [16]

> ABAP изучал сам по книжке, методом тыка, проб и ошибок.

Если она написана на русском языке, то я её, скорее всего, знаю. Для первого ознакомления почитать можно, а потом всё-таки лучше SAP Help.

> Что касаемо специалистов. Меня раздражают 3 уровня между
> программистами и заказчиками.

И какой уровень вы предлагаете исключить?

← →
12 © (2011-02-03 15:01) [27]

>> И какой уровень вы предлагаете исключить?
может, добавить? :)

так хочу работать

1. Заказчик говорит человеку(Ч1), который понимает область разработки и имеет техн.склад ума.
2. Ч1 говорит человеку(Ч2), который умеет немного программировать и немного понимает область разработки, и имеет техн.склад ума. Ч1 и Ч2 составляют план, схему и сроки.
3. Ч2 идет к человеку(Ч3), который умеет программировать хорошо. Ч2 и Ч3 корректируют план, схему и сроки.
4. Ч3 сам делает или в команде. Периодически совещается с Ч2. Если Ч2 не копенгаген - он с Ч1 советуется. Ч1 с заказчиком.

а я где-то в отделе затесался :)

← →
Ega23 © (2011-02-03 15:04) [28]

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

Предпочтительнее вариант создания суррогатного первичного ключа с наложением уникального индекса на все 11 полей.
ИМХО.

> euru © (03.02.11 14:49) [26]
>
> > oxffff © (03.02.11 12:41) [16]
>
> > ABAP изучал сам по книжке, методом тыка, проб и ошибок.
>
>
> Если она написана на русском языке, то я её, скорее всего,
> знаю. Для первого ознакомления почитать можно, а потом
> всё-таки лучше SAP Help.
>
>
> > Что касаемо специалистов. Меня раздражают 3 уровня между
>
> > программистами и заказчиками.
>
> И какой уровень вы предлагаете исключить?

Кречмер? :)

Я ничего не предлагаю. Мне представляется, что нельзя играть на западной балалайке восточные напевы. Три уровня это может быть неплохо.
Однако когда три уровня дублируют функции друг друга и факту просто перетасовывают работу между собой в России.
в итоге попадает программист, который может переделывать алгоритм по 10 раз поскольку уровни заняты собственной важностью.

Знаменитая переписка про рекламный щит очень показательна

http://abelomorov.livejournal.com/1542.html
Читать все части.

> а потом всё-таки лучше SAP Help.

Естественно потом был он. :)

> http://abelomorov.livejournal.com/1542.html

есть и такой случай

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

Теперь звонят и пишут по любой фигне... Даже которой не занимаюсь, даже которой не наш отдел занимается..

Лень искать конкретные номера - о, а этот, судя по коду, из того региона, оттуда, вроде - давай-ка позвоним ему.. А поднял трубку - посылать нельзя :)

вот я дурак.. :))

> 12 © (03.02.11 15:01) [27]

> может, добавить? :)

Развели бюрократию :)

Три уровня - это в большинстве случаев необходимое и достаточное количество:

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

2. Бизнес-аналитик (специалист по модулю SAP) - знает предметную область, хорошо знает функционал модуля (от интерфейса до используемых в модуле таблиц), может оценить целесообразность задачи либо предложить альтернативные решения, в случае необходимости сделать постановку задачи для её реализации.

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

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

В подавляющем большинстве случаев уровни 1 и 3 практически не взаимодействуют.

> Сабж

Нечто похожее у меня сейчас сделано так.

1. Есть интерфейс IExecutable с методом Exec (и другими, если надо).

2. Есть абстрактный класс "Шаг алгоритма", реализующий этот интерфейс.

3. Есть наследники этого класса, в каждом из которых перекрыт метод Exec.
Наследники лежат в пакетах, а все пакеты лежат в обусловленном месте. В каждом наследнике метод Exec выполняет какую-то одну "атомарную" с точки зрения бизнес-логики операцию (например, проверку ФИО или зачисление денег на лицевой счет). Эти классы пишут программисты и постепенно накапливается библиотека шагов - то есть, программисты нужны все меньше и меньше.

4. Написав и отладив шаг, программист регистрирует его, прописывая в БД, в таблицу шагов. В ней указывается русское наименование шага, имя его класса, имя его пакета (и еще что угодно). Таким образом, ядро получает возможность загрузки и выполнения любого шага.

5. В ядре есть класс "Алгоритм", тоже реализующий интерфейс IExecutable. Он содержит упорядоченный список шагов. Метод Exec в нем проходит по этому списку и вызывает метод Exec каждого шага - то есть, выполняет последовательность "атомарных" бизнес-операций. Все эти операции выполняются в одной транзакции и если любой шаг выдал ошибку (или исключение), то выполнение алгоритма прерывается, транзакция откатывается, а юзер получает внятное сообщение (либо оно пишется в лог). Кроме того, любой шаг может прервать выполнение алгоритма и без выдачи ошибки.

6. Есть служебные таблицы БД и их визуальный редактор. В редакторе юзер (точнее, юзерский админ) простыми кликами мышки устанавливает:
- состав шагов каждого алгоритма и их последовательность;
- привязку алгоритма к конкретному типу документа.

Таким образом, один и тот же тип документа у каждого юзера может обрабатываться по-своему и эту настройку делает юзерский админ, просто кликая мышкой и используя готовую библиотеку шагов. Если требуется какая-то специальная обработка, для которой соответствующего шага в библиотеке еще нет, то только тогда привлекается программист для создания и регистрации в БД нового шага. С ростом библиотеки шагов программист становится нужен все меньше и меньше.

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

Кроме того, в библиотеке есть шаги типа "if условие, то перейти к шагу номер N, иначе перейти к шагу номер M" - то есть, алгоритм можно ветвить и зацикливать. Такие настройки тоже делает админ все тем же редактором.

> Ega23 © (03.02.11 15:04) [28]

> Предпочтительнее вариант создания суррогатного первичного
> ключа с наложением уникального индекса на все 11 полей.ИМХО.

Вариант 2 (объединить 11 полей в одно поле) - это и есть суррогатный ключ.

Ваше решение - это объединение двух вариантов, т.е. вы предлагаете в таблице вести два ключа: суррогатный и по всем ключевым полям. Смысл?

> Вариант 2 (объединить 11 полей в одно поле) - это и есть
> суррогатный ключ.

Нет. Суррогатный ключ - тупой счётчик, не несёт никакого логического смысла, кроме того, что гарантированно уникален.
Ну и сравнивать 2 целых числа - гораздо быстрее, чем сравнивать 2 строки длиной 121 символ.

> euru © (03.02.11 16:43) [34]

практически тот же, но не >>объединить 11 полей в одно поле
, а просто сказать СУБД, что эти 11 полей - ключ.

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

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

> а просто сказать СУБД, что эти 11 полей - ключ

Это и есть уникальный индекс. На первичный ключ в разных СУБД могут существовать ограничения (точно не помню, но для, например, MSSQL - общая длина поля, связано с тем, что первичный ключ кластерным индексом является, ну и с размером страницы).

> С ростом библиотеки шагов программист становится нужен все
> меньше и меньше.

А кликающий настройщик плавно превращается в программиста на вновь зародившемся DSL.

И круг повторяется.

;)

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