ViPRosСчас перейду к процессам и процессной количественной семантике, если конечно еще не надоело.Не надоело. Интересная концепция... :)

LSVБоюсь, что более-менее стабильных стандартов нет и не будет. Если бы они были возможны, то их бы давно сделали. Не ? Не дураки же кругом.ПМСМ, будут. Это неизбежно. Как было неизбежно, что на смену "читателям перфокарт" и "программистам на Ассемблере" придут электронные таблицы, доступные всем-всем-всем безо всяких эксклюзивных посредников.

ПМСМ, проблема стандартов разного вида в том, что они... гхм... разного происхождения. Имеются стандарты "родом из" IT-инженерии, то есть, по сути, из "методов чтения перфокарт". И имеются стандарты ведения бизнеса. Изначально они между собой никак не взаимосвязаны. Поэтому на стыке появляется "знахарь-эксклюзив", который каким-то таинственным образом, нашептывая заклинания с непонятными словами, связывает одно с другим. При этом каждый проект по связыванию выступает как уникальный. Но тот, кто связывал уже много раз, подспудно уже знает, что есть какие-то универсальные критерии связывания, просто он их "изобретает" для себя в процессе приобретения опыта. И вот таких "изобретателей велосипеда" бродят по нашей планете целые стада.

Ну, еще в чем проблема? В том, что бизнес-стандарты не до такой степени формализованы. И еще в том, что продвинутые современные технологии менеджмента относительно молоды. Спросите любого достаточно грамотного менеджера "что такое цикл Деминга?" - все знают, что это такое. Но в каких КИС имеется "панель настройки цикла Деминга"? И вообще, какие КИС изначально предполагают ориентацию на работу в условиях постоянных изменений? По-прежнему считается традиционным "водопадный метод", предполагающий предварительную однократную постановку задачи, формирования критериев качества однократно решаемой задачи (внедрения), после чего неимоверными усилиями производится кастомизация по озвученные требования, приемка и... всё, далее задача считается выполненной. И не дай бог кто-нибудь когда-нибудь заикнется о том, чтобы как-то улучшить то, что уже работает! Не дай бог! Работает - и слава богу! Лучше лишний раз не трогать. А как же концепция "постоянных улучшений" Деминга? Она где, в каком месте КИС? Разве не создается ощущения, что кастомизация типичных КИС сродни замешиванию бетона? После того, как он застыл, конечно же, изменить что-то можно, но только ну очень серьезными усилиями. А как же общепризнанные свежепонятые (относительно свежепонятые, всё же уже почти 30 лет прошло с тех пор, как они осознаны мировым бизнес-сообществом) принципы клиентоориентированного менеджмента по-Демингу? Пускай себе живет этот Деминг "где-то там", за пределами КИС?

В каких КИС можно в процессе управления жизненным циклом продукции выстраивать QFD-диаграммы таким образом, чтобы непосредственно на них были бы завязаны базовые параметры IT-систем? Всем известно, что ERP-система "натягивается" на бизнес только после достаточной степени формализации бизнес-процессов, что вообще от прописывания бизнес-процессов при автоматизации никуда не уйти... Но в каких КИС реализовано моделирование бизнес-процессов непосредственно как часть кастомизации системы? В каких КИС мониторинг бизнес-процессов производится именно в соответствии с процессными концепциями менеджмента? Кто из внедривших даже очень дорогую ERP-систему способен сказать, у каких БП и по каким параметрам у него какая сигма процесса?

Да, кругом не дураки. Но слишком "узкоспециализированы". Одни оттачивают менеджмент, не особо задумываясь о том, каким образом полученный результат состыковать с IT-сферой, другие - информационные технологии, и каждый варит суп на своей кухне. Им неизбежно суждено когда-нибудь встретиться. Выработать информационно-менеджментовые общие стандарты, формализовать их. Для этого придется немного преобразиться и менеджменту, и IT-сфере, ПМСМ.

Вот, например, процессная и проектная деятельность. В менеджменте эти два вида деятельности разделяются категорическим образом. Если у тебя есть сертификат PMI (IPMA), значит ты постиг вершины проектного менеджмента! Но как стыкуется проектная деятельность и IT? Те, кто разрабатывал методики менеджмента, не задумывался об этом. А те, кто реализовывал продукты в стиле MS Project, в конечном итоге реализовали "механизацию рукопашного проектного менеджмента". То есть, что-то вроде того, как если бы таджика-канавокопателя с лопатой заменить на робота-терминатора, но всё с той же самой лопатой. А между тем, в сфере менеджмента развели одноразовые процессы и многоразовые процессы по разным областям менеджмента только потому, что у них разные приоритеты. Один из них максимально сконцентрирован на "упреждающей" оптимизации процесса, второй - на статистическом анализе постфактум-событий. В конечном же итоге всё сводится к корректировке схемы выполнения процесса. В информационном же плане и то, и другое остается процессом, к которому приемлемы единообразные подходы. Более того, в процессном и в проектном менеджменте очень много общего - роли, матрица ответственности, мониторинг, возможность оперативной реакции на неблагоприятные события с возможностью корректировки траектории движения, стратегическая часть, тактическая, операционная... Есть, конечно же, и отличия, но отличия можно было бы развести по разным углам уже после того, как выявлены общие компоненты того и этого менеджмента. Ведь это, по сути, это не разные виды менеджмента, а это две нераздельные его части, которые неизбежно присутствуют в любом бизнесе.

Жизненный цикл - он всегда один, поэтому управление жизненным циклом одного конкретного вида продукции - это проект. Но внутри проекта возникает многократно выполняющийся процесс выпуска однотипной продукции, и мы получаем процесс, вложенный в проект. Управление жизненным циклом множества видов продукции - это, опять же процесс, потому что каждый вид продукции требует каких-то повторяемых фаз - маркетинговых исследований, анализа, разработки инновационной модели, ее реализации, опытного запуска процесса производства, промышленного запуска процесса производства. Получается, что проекты вкладываются в процесс, а процессы вкладываются в проект. Рекуррентная схема, которая ДОЛЖНА (ну, то есть, в соответствии с логикой и здравым смыслом, просто обязана ) предоставить возможность эффективного взаимодействия процессов и проектов. Но в какой КИС такое взаимодействие полноценно реализовано? Железобетонные процессы изолированы от проектов, слава богу, в самом выдающемся случае отдельные виды ресурсов у них способны быть общими, и на этом всё взаимодействие заканчивается... Потому что тем, кто размышлял над концепциями менеджмента, удобно было мысленно разделить эти два вида деятельности - вот их и разделили. Экскаватору приспособили две ягодицы - левую и правую, потому что так изначально было у таджика-канавокопателя. И теперь управляющие потоки процессов не способны связываться с фазами проектов и наоборот. Если я ошибаюсь, поправьте. Допускаю, что могу ошибиться.

Но самое главное - изменчивость бизнес-процессов. После того, как я вкусил ее в BPM-системе с версионностью схемы бизнес-процесса, я понял, каким образом может быть реализован (на самом деле!) цикл Деминга внутри КИС. Как сделать КИС не "железобетонной", а реально гибкой, способной к постоянным (каждодневным и даже, может быть, ежечасным) изменениям, которые производятся в рабочем режиме, а не в режиме "кыш все из системы, сейчас будет апокалипсис". Более того, я понял, как управление изменениями самой КИС может быть встроено в виде совокупности проектов и процессов в эту же самую КИС. То есть, система способна контролировать изменения самой себя !

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

Но для этого нужны новые стандарты моделирования. Для которых процессная и проектная модель - это не разные модели, а одна и та же, отдельные части которой имеют нюансы кастомизации. И чтобы рисовал эти модели НЕ IT-шник! И чтобы стыковались они с информационной моделью, структурной моделью и финансовой (бюджетной). И чтобы при необходимости можно было по-человечески реализвать Activity Based Coasting - на базе этих самых моделей, не заходя никуда дополнительно-наружу. И я ЗНАЮ , что всё это - реально возможно. Потому что знаю, КАК это всё следует сделать.

Но самое главное, чтобы такая система не "внедрялась", а "разворачивалась". Внедрение - это проект, а разворачивание - это совершенно другое. Это то, на что способна BPM-система. К сожалению, у тех BPM, которые я знаю, имеются недостатки, связанные либо с одним видом моделирования, либо с другим (но по большей части, с информационной моделью, с которой всё хорошо в классических ERP, но в свою очередь имеются проблемы с моделированием БП и проектов). А я хочу, чтобы совокупность моделей, декомпозируемых, изящных, понятных и информационно-полных могла бы полностью определять функционал КИС. И чтобы используемая КИС не шла "своей дорогой на свою кухню" мимо современных концепций менеджмента, а позволяла бы использовать и канбан, и циклы DMADV и DMAIC, и реализовать "цифровой поток" Lean, и оптимизировать загрузку оборудования методами линейного программирования по TOC, и контролировать управляемость бизнес-процессов и их устойчивость (а в идеале, и технологических - тоже). Чтобы изначально чтобы КИС могла на практике реализовывать концепции клиентоориентированности. Чтобы система KPI брала свое начало от QFD. И чтобы QFD задавала базовые параметры всех процессов и проектов. Чтобы в КИС был встроен инструментарий управления робастностью процессов и продукции по методам Тагутти...

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

s_ustinovGarya
Различные виды учета активов и их источников (РСБУ, МСФО, НУ, УУ) реализуется на уровне сервисов, по отдельному сервису на каждый вид учета.

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

Аналогичные проблемы будут с тем функционалом, который внутри достаточно сложен и требует для работы достаточно разнородную информацию. Тот же учетный модуль - ему нужны суммы, валюты, курсы, даты, виды операций, счета (ТХО) причем или "стандартные" или указанные вручную и т.д.Всё делается достаточно просто. Стандартизируется схема взаимодействия примитивов модели с WEB-сервисами. И отдельно - визуализация. И всё... :)

ViPRos...все отношения в которых участвует предприятие спокойно ложатся в схему "клиент-сервер" в процессной модификации...Похоже, наши мысли едут одним курсом. :)

s_ustinovнаверно, мозг отвыт работать с настолько абстратной информацией )))
если я правильно понял, то при продаже процесс продажи должен соединится с процессом "учет по МСФО" и выдать ему всю необходимую информацию. и вот тут у меня появляется мысль, что такой процесс "учет по МСФО" будет довольно сложным - он ведь должен уметь обрабатывать кучу "событий" - продажа, переоценка ос, пересчет нереализованных курсовых разниц и т.п.
и у каждого такого события (продажа, закупка) есть куча параметров (сумма, валюта, тип события и куча дополнительной информации для правильного выбора счетов учета + аналитики). и вот если например нам нужен еще и учет по РСБУ, то наборы параметров для этих процессов (мсфо и рсбу) будет в общем случае разным - и не станет ли в результате система в целом слишком сложной и неповоротливой? и создание нового процесса ("передача ос в аренду") не будет ли крайне сложной операцией? ведь нам мало того что надо в новом процессе прописать передачу параметров процессам мсфо и рсбу, но надо будет еще и дописать учетные процессы (мсфо и рсбу), чтобы они понимали новый вид события. а ведь потенциально могут быть затронуты еще и другие процессы - например "расчет амортизации на основе выработки"...Проблема лишь в преодолении шаблонов восприятия. Я сейчас крамольные мысли буду говорить, и в меня начнут кидаться тухлыми помидорами АБ и WJ (если догадаются прочитать, что я написал, гы-гы :) ). Я вот имею наглость утверждать, что "бизнес-процессы бухгалтерского учета" - возможны (опасливо оглядываюсь, не выскочит ли из-за угла АБ). Я уже несколько раз упоминал о том, что в ИНФИНе, например, можно реализовать ЦЕПОЧКИ (своего рода, "процессы"), в которых смешиваются концепции учета "от проводки" и "от документа". Может формироваться документ, потом проводки, потом снова документ, потом снова проводки, и каждая фаза такой цепочки может использовать информацию с любых предшествующих фаз + общий массив накопленной в системе информации. Но это еще недостаточно крамольно... :) Я сечас такое озвучу, что все вообще в обморок попадают... :)

Представьте себе "процесс", описанный в нотации BPMN , заполнения экранной формы....

...
...

(длинная многозначительная пауза)

...
...

Не верите, что такое возможно? Сходите по ссылке. Видите там такие объекты потока управления "events"? Попробуйте домыслить, можно ли по ним управлять поведением мышки при перемещении ее над эллементом управления... :)

Тьфу, самое главное не сказал...

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

LSVпо сабжу: не взлетит .
Почему ?
Потому-то эти в модели общем случае в сто раз сложнее, чем нужно в жизненной ситуации.
Эта система будет сложнее чем все САПы вместе взятые.
Все равно, что "для включения радиоприёмника нужно изучить теорию поля".
Или "чтоб положить кирпич - выучить теорию гравитации".
Неполная модель будет ущербна, полная модель - неимоверно сложна и избыточна.
Правильность, доведенная до абсурда.

Кароч. полнейшая, нежизнеспособная фантастика, ИМХО.
Что бы там не говорили.

ЗЫ: "Усложнить может каждый дурак. Только умный способен упростить." (с)ПМСМ, всё с точностью до наоборот. Разработка КИС "от бизнес-процессов", которые сначала набрасываются крупными мазками, а потом детализируются - это самый простой способ разработки, максимально приближенный к "объектной модели" предметной области. При этом технология описания бизнес-процессов верхнего уровня и обработки информации на самых нижних уровнях - одна и та же. Не нужно изучать отдельно инструментарий, с помощью которого выстраивается процессная модель и отдельно - языки программирования, RAD, какую-то среду, с помощью которой процессная модель должна быть реализована, но уже совершенно в другой, инородной семантике... Всё делается ОДНОТИПНО .

Более того, "от-процессный" подход к разработке приложений, ПМСМ, формирует новый тип мышления и позволяет сконцентрироваться не на вопросах взаимодействия интерфейсов, не на правильном построении синтаксических конструкций и т.д. и т.п., а на алгоритмах ВЗАИМОДЕЙСТВИЯ компонентов бизнеса между собой и с людьми. Это очень важно, что для разработки и кастомизации сложных бизнес-приложений больше не нужны "знахари-дешифровальщики перфокарт". Приложение возникает "само-собой" после того, как формализованы процессы вплоть до самого низкого уровня их декомпозиции. Процессная модель - это универсальная модель, с помощью которой может быть описаны все компоненты бизнеса, технологических процессов и самые мелкие нюансы работы пользовательского интерфейса... Точнее, она может стать такой, если стандарт BPMN версии 2.0 будет расширен таким образом, что в этой же модели реализуется информационная модель, структурная модель и оказываются выделяемыми (описываемыми) нюансы проектной и процессной компонент управленческой деятельности.

s_ustinovGaryaВсё делается достаточно просто. Стандартизируется схема взаимодействия примитивов модели с WEB-сервисами. И отдельно - визуализация. И всё... :)
вот что то сомнения меня берут )))
например, те же права доступа...
хотя может я просто не моу себе все это правильно представитьНу, поработать, конечно же, есть над чем. Но в том же ИНФИНе, например, вполне реально определить, кто может запускать какую цепочку, а кто не может. И также определяются отдельно права доступа к счетам и к справочникам.

Однако, модель безопасности ИНФИНа - это не только не идеал, она базируется на всё тех же привычных категориях (классификациях) объектов, которыми оперирует система. Я же исхожу из более продвинутой идеи. Поскольку процессная модель ОДНОРОДНА (!!!) на всех своих уровнях, для нее может применяться концепция однородного же задания прав доступа. То есть, можно задать права доступа к бизнес-процессу, к отдельным его операциям, к компонентам информационной модели вроде счетов учета, и даже к контролам, которые появляются на экране. И всё это - однотипным способом без множественного расплодения сущностей без необходимости.

ViPRosПрава в зачаточном состоянииНе понял. Где? В моей концепции или где-то еще?

Я не вдаюсь в подробности, но когда многие традиционно-разные классы объектов можно свести к одной системе объектов в виде их совокупности с взаимосвязями в рекуррентнной модели, то права могут назначаться на сложные совокупности "традиционно-разнородных" объектов, могут быть задействованы механизмы наследования прав доступа нижними уровнями модели с верхних (разумеется, только тогда, когда в этом есть необходимость). Кроме того, можно объект "роль" концепции BPMN непосредственно увязать с ролью системы безопасности. При этом само обеспечение безопасности может быть формализовано и фиксировано в системе как некая совокупность бизнес-процессов, в которой на базе унифицированных стандартных процедур в соответствии с ITIL обеспечивается предоставление доступа на основе заявок, заполненных по стандартной форме лицами, которым предоставлены соответствующие полномочия и проходящих процедуру согласования, изменяются права доступа при изменении перечня должностных полномочий и выполняемых сотрудниками функций, и исключается доступ при их увольнении. То есть, обеспечены все необходимые требования компоненты "Access Management" ITIL - не за пределами КИС, а непосредственно в ней.

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

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