Если мы применим эти критерии к обиходным на практике языкам моделирования, сразу станет понятно, почему ими могут пользоваться только «эксперты»: при большом количестве элементов моделирования, главным образом «приправленных» пиктограммами (эффект узнавания должен означать простоту и облегчать понимание), предпринимается попытка во всех мыслимых прикладных областях передать наглядное отражение реальности. За такое разрастание синтаксиса приходится платить поразительно расплывчатым определением семантики.
Взгляд на смежную область моделирования данных демонстрирует ошибочность этого пути. Там вместе с реляционной моделью данных Теда Кодда и связанным языком запросов SQL в качестве отраслевого стандарта утвердилась математически обоснованная модель с синтаксически простым языком. Сети Петри также обладают этими «удачными особенностями»: простейший синтаксис с математически четко определенной семантикой, которые наряду с недвусмысленной интерпретацией элементов модели также включают в себя динамические свойства в форме переходов состояний. Таким образом, сети Петри предлагают разнообразные возможности для статического анализа и динамического имитационного моделирования. Введение в сети Петри в доступной форме вы найдете в главе 3.
1.2.2. Методы моделирования
Простота применения в сочетании с разнообразием возможностей использования – эти сильные стороны сетей Петри наилучшим образом раскрываются тогда, когда они составляют одно целое с испытанным методом моделирования. Метод регламентирует, когда сети Петри принесут пользу и каким образом. И он также регулирует, когда и как следует использовать анализ и имитационное моделирование и какие результаты с их помощью могут быть достигнуты.
Конкретный метод работы с сетями Петри в бизнес-сообществах представлен в главе 4 этой книги.
1.3. Инструменты для бизнес-сообществ
Продуктивная работа с сетями Петри и применение соответствующих методов немыслимы без поддержки программных инструментов. Инструменты обеспечивают соблюдение синтаксических правил, поддерживают методологические этапы и берут на себя задачи администрирования, документирования и использования созданного контента.
История проектирования бизнес-процессов на основе моделей тем временем возвращает нас назад более чем на 20 лет. После первых нерешительных начинаний в области средств автоматизированной разработки программного обеспечения (Computer-aided software engineering – CASE) моделирование бизнес-процессов пережило первый расцвет в контексте внедрения стандартных бизнес-приложений (SAP, приложения Oracle, PeopleSoft, Baan и т. д.). Помимо таких высокопрофессиональных инструментов, как ADONIS, ARIS, Bonaparte, Casewise и INCOME, на рынке появлялось все больше и больше низкотехнологичных средств, получивших развитие от простых графических программ, например Visio и iGrafx. Между тем сейчас мы наблюдаем второй расцвет, движущими силами которого, несомненно, служат темы управления бизнес-процессами (Business Process Management – BPM), разработка, управляемая моделями (Model Driven Development – MDD) и сервис-ориентированная архитектура (Service Oriented Architecture – SOA). Актуальные обзоры рынка показывают, что сегодня практически каждый поставщик прикладного и межплатформенного программного обеспечения может предложить по крайней мере один инструмент моделирования процессов.
Однако при ближайшем рассмотрении таких инструментов быстро выясняется, что они пригодны для использования в бизнес-сообществах только в ограниченном масштабе. Они требуют высокого уровня подготовки и навязывают пользователям образ действий, обусловленый не их нуждами, а особенностями программного средства. В большинстве случаев уровень сложности слишком высок (пример: многочисленность типов моделей в ARIS) либо ограниченные возможности абстрагирования уж слишком навязывают пользователю уровень реализации (пример: моделирование с BPMN), препятствуя важным творческим процессам моделирования. Но в «оправдание» подобных инструментов стоит отметить, что они возникли главным образом в то время, когда надобность участия целиком бизнес-сообществ в разработке бизнес-процессов еще не была признана и технические возможности для обеспечения продуктивной совместной работы (ключевое слово: Web 2.0) также еще не были в нашем распоряжении.
1.3.2. Horus: Бизнес-процессы для бизнес-сообществ
Читать дальше