вопрос типа такого, хотим внедрять ERP, есть бизнес-процессы "AS IS"

какова методология описания бизнес-процессов, чтобы отрисовать то, что есть и чтобы это оптимизировать под:

1) российские реалии
2) чтобы было лучше, чем сейчас
3) чтобы потом все гармонично легло на ERP

?

интересует собственно подход к этому вопросу, что можно почитать на эту тему ?

Shuhard http://www.finexpert.ru/

ссылки у них в мозилле не работают. все сайты как сайты, а эти ... эх

Прохожий.. Илья Шипицин
..
1) российские реалии
2) чтобы было лучше, чем сейчас
3) чтобы потом все гармонично легло на ERP
..

В этом гос-ве принято ,что западные ERP "гармонично кладут" на
наши "реалии" :)
Молодой человек, Вам следует искать более адекватную и честную работу в
сфере ИТ. А "ERP" здесь еще долго будут нужны только как средство
отмыва бюджетных денег.

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

то есть, возьмем некоторое предприятие, в нем варятся какие-то свои доморощенные бизнес-процессы. не всегда эффективные, не всегда допускающие as is внедрение в дальнейшем ERP системы.

вот! а потом приезжают консалтеры и говорят "тэкс... это убрать, вместо этого сделать так....", собственно, интересует этот процесс. по идее этому должны учить в институтах (название учебной дисциплины ?) и на основании этих подходов к управлению должны быть построены ERP системы (название предметной области ?)

АББизнес-процессы и ERP -- это далеко не синонимы. Современный подход к бизнес-процессам основан не на ERP и не на системах документооборота, а на новом классе ПО -- т.н. BPMS системах (Business Process Management Systems). В отличие от традиционных "рисовалок" (типа Aris и прочих средств реинжиниринга), на выходе которых вы получаете картинки и тексты, BPMS реально и непосредственно управляет бизнес-процессами. Что касается ERP, то с этим тоже все в порядке: BPMS специально заточены под интеграцию корпоративных приложений, имеют специальные коннекторы для стыковки с ними, благодаря чему разработчик имеет возможность органически вписать их функционал в контекст бизнес-процесса. Средств таких сейчас появляется довольно много, мы в нескольких проектах использовали Unify kis.pcweek.ru/Year2004/N39/CP1251/DevApp/chapt2.htm , получается очень эффективно. Я на эту тему могу распространятся долго, если есть интерес -- задавайте вопросы.


зазырил!
ничего не понятно :-)

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

АБ Илья Шипицинничего не понятно :-)
И это нормально! :)

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

Объясняю "на пальцах" как эта штука работает:
1) Рисуете схему. Схема похожа на workflow диаграмму: процессы, переходы, ролевые группы. На IDEF0/DFD не похожа.
2) Делаете ей deploy на java-сервер (на встроенный JBoss или уже имеющийся от IBM, Oracle и прочих).
3) Заводите пользователей, нарезаете им права.
4) С этого момента можно уже работать: пользователь, входя в систему, видит "мой список задач". Отработал свою задачу, нажал кнопку -- процесс перешел в следующее состояние (то или другое, в зависимости от того какую кнопку нажал) и становится задачей пользователя из другой рабочей группы. Интерфейс на этом этапе довольно примитивный, но зато можно начать "щупать" буквально за полдня.
5) Чтобы получить более качественный интерфейс и провязать бизнес-процесс с нижележащими ERP, собственными системами, базами данных или в конце концов просто Excel файлами, нужно подключить программеров. На это уйдет уже порядка недели (исходя из пары десятков форм для одного более-менее развесистого бизнес-процесса). Архитектура приложений -- тонкий клиент (DHTML) и java на стороне сервера.

Что можно делать при помощи BPM (примеры наиболее выигрышных применений)
1) отслеживание клиентских заказов от коммерческого предложения через согласование спецификаций, технологов, производственников и до бухгалтерии и счетов-фактур
2) бюджетные процессы в холдингах -- многоуровневые согласования при утверждении и бюджетный контроль при закупках
3) прием на работу и увольнение ("бегунок" при увольнении -- это ж бизнес-процесс в натуре)

Общее правило: эффект тем значительнее, чем больше подразделений задействовано в процессе, чем дальше они друг от друга отстоят по административной иерархии и географически и чем больше экземпляров процесса проходит за единицу времени.

Теперь немного понятнее? :)

неа, непонятно. J2EE апликейшен сервер - это то, на чем реализован данный конкретный продукт ? а сам подход где описан ?


"1) Рисуете схему. Схема похожа на workflow диаграмму: процессы, переходы, ролевые группы. На IDEF0/DFD не похожа."

можно поподробнее про рисование схемы ? по каким правилам она строится и где об этом можно почитать ?

и самое главное, как потом от прорисованной схемы перейти к оптимизации процессов ? то есть должна быть какая-то процедура (понятная мне, человеку, успешно отучившемуся в ВУЗе) и должен быть критерий, что да, вот это состояние, которое новое - оно более эффективно, чем то, что было раньше.

АБИлья, извините, без наезда, но -- какой ВУЗ Вы заканчивали? Просто J2EE это, похоже, не Ваша область, бизнес-процессы тоже не совсем...

ОК, теперь по существу.

1) J2EE -- это платформа, на которой реализован и данный продукт, и вообще большинство BPM решений. Это достаточно важно для IT-профессионалов, потому что выбор платформы всегда определяет ряд фундаментальных как преимуществ, так и ограничений предлагаемого решения. Причем, что особенно ценно, они не зависят от того, какую песню поет клиенту продавец.

2) Если Вы никогда не рисовали схем бизнес-процессов, то, по собственному опыту, я бы рекомендовал посетить семинар на эту тему.

3) Вопрос про оптимизацию -- очень хороший! Применительно к BPM, тут надо отметить два момента.

Во-первых, BPM заточен под то, чтобы выполнять разработку очень быстро . Традиционный подход следующий: несколько месяцев рисуем бизнес-процессы, потом как минимум год программеры "вколачивают бизнес-процессы в функционал" (есть такой жаргонный термин). В итоге система устаревает до того, как ее успевают сделать. В BPM счет реализации идет максимум на недели, и это революционизирует весь подход к делу. Если обычно вам говорят "сначала наведите порядок в бизнес-процессах, а уже потом..." (слышали такие речи?), то здесь подход принципиально другой: непрерывный реинжиниринг собственными силами. BPM -- это не только средство автоматизации, но одновременно и мощнейшее средство выявления (inspection) бизнес-процессов. Начинаешь работать по схеме более-менее as-is, моментально понимаешь каким должен быть очередной to-be, с минимальными трудозатратами переходишь к нему... для того чтобы увидеть новый to-be, и так без конца.

Во-вторых, любой BPM помимо средств разработки и исполнения бизнес-процессов содержит в себе средства анализа, business intelligence. Только представьте: ведь по результатам эксплуатации BPM-системы у вас накапливается ценнейшая статистика: сколько времени занимает бизнес-процесс в целом и отдельные шаги, кто тормозит, какая нагрузка на сотрудников... Все узкие места сразу видны. Сейчас говорят уже о том, что эту статистику надо обрабатывать так, чтобы напрямую давать показатели balanced scorecard. И это наверное правильно, но на мой взгляд это эффекты все же второго порядка по сравнению с тем, какой мощный эффект дает BPM от элементарной расчистки бардака, постоянного и плотного отслеживания "на ком стрелка", от интеграции людей и программ.


ЧелГУ заканчивал, специальность теоретическая физика.


насчет платформы, мне больше нравится XML, например :-) что-нибудь типа www.xmldb.com, хотя по наработкам J2EE, безусловно, побогаче.

сарказм по поводу платформы потому, что речь не о платформе, а о том, на чем она базируется. есть Tomcat, который реализует стандарт веб-апликейшен и http/1.1, а есть собственно стандарты веб-апликейшена и http/1.1

изучение Tomcat-а я бы лично рекомендовал начинать непосредственно с предментной области. клиент-серверная модель, между которыми бегает http/1.1 ... ага, уже что-то понятно.... а не так, что сразу берем, ставим Tomcat и начинаем чего-то под него программировать.

поэтому и в данном случае, Вы говорите "поставим JBoss и проинсталируем на нем это дело!", я говорю, стоп, подождите, а по каким принципам это работает ?

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

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

АБЗдравствуйте коллега! Я тоже учился на физика :)

Нет, XML нельзя сравнивать с J2EE (хотя мне XML тоже нравится). Но XML, в отличие от J2EE (и .NET), нельзя назвать платформой для корпоративных приложений.

Далее, Tomcat -- это НЕ J2EE сервер, а "всего лишь" контейнер сервлетов. JBoss (который, кстати, Tomcat в себя включает) -- это другое дело, он прошел все тесты и официально сертифицирован на совместимость со спецификацией J2EE. Поэтому тут места для скепсиса немного.

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

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

Есть относительно новая область BPMS. По ней только онлайновые ресурсы, и в основном на английском. Гуглите и обрящете!


я в курсе, что есть J2EE и что есть Tomcat :-) я и не называл его J2EE сервером, просто проводил параллели. любая корпоративная платформа реализует какие-либо технологии, J2EE ценно не само по себе, а по его прикладному применению, которое описывается предметной областью. тот же самый Compiere, вполне написан на J2EE, правда, кроме как под JBoss-ом почему-то не работает :-) а вот понять принципы, которые заложены в Compiere- я так и не смог. но это не бухгалтерия, по-любому. а еще не смог понять как те процессы, которые есть, перенести под Compiere.

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