Форум: "Прочее";
Текущий архив: 2011.05.22;
Скачать: [xml.tar.bz2];
ВнизОпрос: Как вы учитываете изменения в бизнес-процессах Найти похожие ветки
← →
Игорь Шевченко © (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 полей.
ИМХО.
← →
oxffff © (2011-02-03 15:05) [29]
> 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
Читать все части.
← →
oxffff © (2011-02-03 15:25) [30]
> а потом всё-таки лучше SAP Help.
Естественно потом был он. :)
← →
12 © (2011-02-03 16:04) [31]
> http://abelomorov.livejournal.com/1542.html
есть и такой случай
я, как дурак, на корпоративном сайте подписывался с визиткой внизу.
По-идее, так и нужно всем. Но у всех в профиле, а я решил для удобства пользователей, чтоб лишний раз не тыкали...
Теперь звонят и пишут по любой фигне... Даже которой не занимаюсь, даже которой не наш отдел занимается..
Лень искать конкретные номера - о, а этот, судя по коду, из того региона, оттуда, вроде - давай-ка позвоним ему.. А поднял трубку - посылать нельзя :)
вот я дурак.. :))
← →
euru © (2011-02-03 16:37) [32]
> 12 © (03.02.11 15:01) [27]
> может, добавить? :)
Развели бюрократию :)
Три уровня - это в большинстве случаев необходимое и достаточное количество:
1. Ключевой клиент (заказчик, пользователь) - хорошо знает предметную область, может объяснить поставленную задачу с точки зрения бизнес-логики, принимает дополнительные решения по возникающим по ходу разработки вопросам.
2. Бизнес-аналитик (специалист по модулю SAP) - знает предметную область, хорошо знает функционал модуля (от интерфейса до используемых в модуле таблиц), может оценить целесообразность задачи либо предложить альтернативные решения, в случае необходимости сделать постановку задачи для её реализации.
3. Системный аналитик (программист) - знает функционал, хорошо знает инструменты разработки, может оценить поставленную задачу и выбрать оптимальный способ её реализации, оформить техническое задание и на его основе реализовать поставленную задачу.
Естественно, каждый уровень может состоять при необходимости из нескольких человек.
В подавляющем большинстве случаев уровни 1 и 3 практически не взаимодействуют.
← →
Юрий Зотов © (2011-02-03 16:38) [33]> Сабж
Нечто похожее у меня сейчас сделано так.
1. Есть интерфейс IExecutable с методом Exec (и другими, если надо).
2. Есть абстрактный класс "Шаг алгоритма", реализующий этот интерфейс.
3. Есть наследники этого класса, в каждом из которых перекрыт метод Exec.
Наследники лежат в пакетах, а все пакеты лежат в обусловленном месте. В каждом наследнике метод Exec выполняет какую-то одну "атомарную" с точки зрения бизнес-логики операцию (например, проверку ФИО или зачисление денег на лицевой счет). Эти классы пишут программисты и постепенно накапливается библиотека шагов - то есть, программисты нужны все меньше и меньше.
4. Написав и отладив шаг, программист регистрирует его, прописывая в БД, в таблицу шагов. В ней указывается русское наименование шага, имя его класса, имя его пакета (и еще что угодно). Таким образом, ядро получает возможность загрузки и выполнения любого шага.
5. В ядре есть класс "Алгоритм", тоже реализующий интерфейс IExecutable. Он содержит упорядоченный список шагов. Метод Exec в нем проходит по этому списку и вызывает метод Exec каждого шага - то есть, выполняет последовательность "атомарных" бизнес-операций. Все эти операции выполняются в одной транзакции и если любой шаг выдал ошибку (или исключение), то выполнение алгоритма прерывается, транзакция откатывается, а юзер получает внятное сообщение (либо оно пишется в лог). Кроме того, любой шаг может прервать выполнение алгоритма и без выдачи ошибки.
6. Есть служебные таблицы БД и их визуальный редактор. В редакторе юзер (точнее, юзерский админ) простыми кликами мышки устанавливает:
- состав шагов каждого алгоритма и их последовательность;
- привязку алгоритма к конкретному типу документа.
Таким образом, один и тот же тип документа у каждого юзера может обрабатываться по-своему и эту настройку делает юзерский админ, просто кликая мышкой и используя готовую библиотеку шагов. Если требуется какая-то специальная обработка, для которой соответствующего шага в библиотеке еще нет, то только тогда привлекается программист для создания и регистрации в БД нового шага. С ростом библиотеки шагов программист становится нужен все меньше и меньше.
Это канва. В реальности все выглядит несколько хитрее. Например, любой шаг алгоритма может иметь параметры и работать в зависимости от их значений. Имена и количестов параметров устанавливает программист и, прописывая шаг в БД, там же прописывает имена и дефолтные значения параметров. Однако, админ юзера может изменить фактические значения параметров (тем же самым визуальным редактором) и сделать так, что один и тот же шаг получит разные значения параметров в зависимости от типа обрабатываемого документа.
Кроме того, в библиотеке есть шаги типа "if условие, то перейти к шагу номер N, иначе перейти к шагу номер M" - то есть, алгоритм можно ветвить и зацикливать. Такие настройки тоже делает админ все тем же редактором.
← →
euru © (2011-02-03 16:43) [34]
> Ega23 © (03.02.11 15:04) [28]
> Предпочтительнее вариант создания суррогатного первичного
> ключа с наложением уникального индекса на все 11 полей.ИМХО.
Вариант 2 (объединить 11 полей в одно поле) - это и есть суррогатный ключ.
Ваше решение - это объединение двух вариантов, т.е. вы предлагаете в таблице вести два ключа: суррогатный и по всем ключевым полям. Смысл?
← →
Ega23 © (2011-02-03 16:48) [35]
> Вариант 2 (объединить 11 полей в одно поле) - это и есть
> суррогатный ключ.
Нет. Суррогатный ключ - тупой счётчик, не несёт никакого логического смысла, кроме того, что гарантированно уникален.
Ну и сравнивать 2 целых числа - гораздо быстрее, чем сравнивать 2 строки длиной 121 символ.
← →
12 © (2011-02-03 16:52) [36]
> euru © (03.02.11 16:43) [34]
практически тот же, но не >>объединить 11 полей в одно поле
, а просто сказать СУБД, что эти 11 полей - ключ.
← →
12 © (2011-02-03 16:54) [37]
> Юрий Зотов © (03.02.11 16:38) [33]
а, по-чесноку, это работает?
в том смысле, что не "вот-вот еще допилим и они потом сами будут", а реально, они сами, средней сложности логику, строят?
← →
Ega23 © (2011-02-03 16:55) [38]
> а просто сказать СУБД, что эти 11 полей - ключ
Это и есть уникальный индекс. На первичный ключ в разных СУБД могут существовать ограничения (точно не помню, но для, например, MSSQL - общая длина поля, связано с тем, что первичный ключ кластерным индексом является, ну и с размером страницы).
← →
DiamondShark © (2011-02-03 16:56) [39]
> С ростом библиотеки шагов программист становится нужен все
> меньше и меньше.
А кликающий настройщик плавно превращается в программиста на вновь зародившемся DSL.
И круг повторяется.
;)
← →
Ega23 © (2011-02-03 16:58) [40]
> Юрий Зотов © (03.02.11 16:38) [33]
во, мы тоже подобную схему реализовывали.
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2011.05.22;
Скачать: [xml.tar.bz2];
Память: 0.59 MB
Время: 0.005 c