sobolevGarya
Я давно на эту тему свой мозг чешу. И кое-что уже начесал... :) Более того, я теперь хочу найти площадку, на которой смог бы развернуться со своими идеями. Можно создать революционный продукт, который просто не имеет аналогов на рынке систем автоматизации. За базу хочу взять какой-нибудь уже готовый продукт, в котором уже реализована существенная часть того, что должно быть реализовано.
Подробности будут?Ок. Кое-что расскажу.

Унификация и стандартизация - очень важная компонента, но, к сожалению, существующие стандарты моделирования бизнеса содержат массу недостатков. К примеру, один из наиболее "древних" стандартов IDEF0, изначально разработанный для моделирования бизнес-процессов, имеет множество недостатков, по которым он не может использоваться для автоматизированного синтеза необходимого функционала КИС. Это известная вещь, детально останавливаться на ней не буду. И, вроде бы, для решения проблем с этим стандартом разработаны новые стандарты, базирующиеся на XML - BPEL, BPEL2People (язык описания бизнес-процессов) и BPMN (нотация). Самое же забавное то, что эти стандарты тоже содержат "врожденные болезни". В частности, ни один из них не предполагает интеграции ни со структурной моделью бизнеса, ни с информационной. Что делать? Придумывать новый стандарт?

Нет. Я предполагаю оттолкнуться от BPMN v.2.0. ПО крайней мере, в этом стандарте есть самое необходимое для интеграции с двумя другими моделями - со структурной и с информационной. "Роль" BPMN должна выбираться из заранее разработанной структурной модели. Это привносит некоторые ограничения при моделировании. С одной стороны, возникает некоторое "неудобство", связанное с тем, что невозможно определить роль, которая не задана структурной моделью. С другой стороны, именно такое положение, когда формально определены одни роли, а на практике реализуются другие, в процессе описания системы автоматически устраняется. Структурная модель, модель БП и информационная модель не должны противоречить друг другу, и все формальные противоречия устраняются на фазе описания моделей путем одновременного приведения внутренних формальных документов и регламентов в согласованное состояние.

Над выбором стандартов построения информационной и структурной модели я еще продолжаю ломать голову. Те, которые мне известны, по ряду причин мне не нравятся. Самая главная причина - они плохо стыкуются с моделью бизнес-процессов. Возможно, придется разработать проприетарный набор инструментов для моделирования, отталкивающийся от BPMN v.2.0. Я предполагаю "присовокупить" к средствам моделирования в нотации BPMN прямые "выходы" на информационную и структурную модель бизнеса. Информационную модель предполагаю описать в виде каталога WEB-сервисов в совокупности со схемой их информационного взаимодействия. Модель данных тоже имеет быть, но в пределах одной WEB-службы. Интеграция данных между множеством WEB-сервисов осуществляется построением "опорных" WEB-сервисов, описывающих общие данные.

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

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

Таким образом, четыре базовые модели бизнеса + модель данных должны полностью описывать функционал прикладной системы. Три базовые модели - модель БП, проектная модель и структурная модель настраиваются НЕ IT-специалистом, а "специалистом по бизнесу". IT-специалист используется при построении информационной модели, разработке и доработке WEB-сервисов и моделей данных.

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

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

Примерно так...

Андрей Ж.GaryaЯ давно на эту тему свой мозг чешу. И кое-что уже начесал... :) Более того, я теперь хочу найти площадку, на которой смог бы развернуться со своими идеями. Можно создать революционный продукт, который просто не имеет аналогов на рынке систем автоматизации. За базу хочу взять какой-нибудь уже готовый продукт, в котором уже реализована существенная часть того, что должно быть реализовано.
Извините ... Надеюсь когда-то "осмелюсь" на пиар своей системы, ориентированной правда на микробизнес, но её одна из основных концепций - "виртуальные объекты" как раз является теми "кубиками" из которых строится "решение" для конкретного предприятия (набора бизнес процессов). В теории всё просто имеем реальный объект, например "накладная", но к ней прицепляется "виртуальный объект", например "схема перемещения изделия в процессе производства" или "бухгалтерская проводка"... Может "простота" концепции вызовет отторжение, но всё таки внимательно прочитайте "электронный учебник" http://www.zhsoft.nm.ru/hand_rep/hand_rep.htm и может быть некоторые идеи "SkyNet" Вам пока жуть ся интересными?Спасибо, ознакомлюсь, но чуть попозже. Сейчас должен отлучиться - много работы.

ViPRosСтруктуры легко сводятся к процессам
Процессы = Трансформирующие(трансформирующие, транслирующие с задержкой, мгновенно, по наступлению синхрособытия и т.д.) транзакции.
Межпроцессные потоки дополняют идентификационно-числовую семантику.
Нужен хороший классификатор, хороший построитель связей, хороший визуализатор. И дело в шляпе. :)
Приходи в гости, может останешься. :)Такое представление имеет право на существование, но оно не решает ту задачу, которую пытаюсь решить я... :)

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

s_ustinovGarya
У меня есть свой ответ на эти вопросы. Унификация и кубики - да, они должны быть. Кубики должны быть "операбельны" для работы с ними теми людьми, которые отвечают за бизнес-функции и бизнес-процессы (то есть, не только для специалистов-кастомизаторов ERP-систем). Но это не готовый функционал. Это инструменты моделирования бизнеса, базирующиеся на построении информационной модели бизнеса, структурной модели бизнеса, процессной модели бизнеса и его проектной части. И все эти четыре составляющие должны взаимно проникать друг в друга и формировать сразу же действующий функционал автоматизируемых систем, которые опираются на четтыре взаимно проникающие модели одного бизнеса.


Если при этом будут готовые "шаблоны", которые можно изменять или при необходимости переписывать - то да, это будет очень интересное решение. По опыту могу сказать, что у большинства предприятий минимум 80-90 процентов всех бизнес процессов или стандартные, или близки к стандартным. или они не имеют ничего против того, чтобы заменить на стандартные (и такая замена проходит легко).
Причем мне кажется, что самые большие преимущества проявятся не на этапе внедрения, а при эксплуатации - постоянно что-то в процессе работы желательно изменить или добавить, и возможность это делать относительно легко очень важна.
Но как сделать такую систему, лично я не представляю...Да, разумеется. Необходимо разработать некие базисные процессы, вроде БД "Борей" в MS Access. С примерами решения наиболее заковыристых задач. В каждом конкретном случае кастомизатор будет брать то, что ближе всего к его ситуации, и просто "подкручивать".

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

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

LSVСамое сложное здесь - создать толковый компилятор и IDE.
Но что фантастичного в прочих пунктах ? Наверное, я не совсем корректно выразился. Просто, ПМСМ, кубики, из которых всё складывается, должны быть не в виде готового функционала такого-то или сякого-то, а в виде примитивов, из которых моделируется БП в BPMN.

LSVзы: так почему до сих пор нет такого толкового конструктора ?
Ведь нет проблемы его создать.Сам удивляюсь.

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

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

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

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

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

ViPRosЕсли интересно, то расскажу дальше.
Кстати, ИТ тут вообще не при чем.Конечно же, интересно. Валяйте... :)

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