Замусоривание Великого и Могучего обломками бритвы Оккама (апология иноязычных неологизмов)
Trashing of The Great and Might by The Scrap of The Okkam`s Razor (An Apology of The Foreign-language Neologisms)

В статье рассматриваются вопросы допустимости и необходимости использования иноязычных неологизмов при формулировании новых концепций в специальных проблемных областях. Также в статье затрагиваются общие проблемы человеко-компьютерного взаимодействия и возникновения знаний и языков на заре развития человечества. Read the rest of this entry…

Учётные системы как специальная категория программного обеспечения

За последние два десятка лет мне доводилось разрабатывать на заказ программные системы в самых разных предметных областях. И регулярно я ловил себя на чувстве, что отлаживаю один и тот же код. Дело в том, что несмотря на различие предметных областей (банковские, логистические, торговые, производственные) всех их объединяет то, что по сути они ведут учёт одного и того же — объектов учёта.
А природа этих объектов учёта не так уж важна с точки зрения программного кода.
И в конечном счёте всё это системы управления бизнесом, или, точнее системы управления бизнес-процессами.
Вот об автоматизации управления бизнес-процессами я и хотел бы поговорить в этой статье.
Я предлагаю использовать термин «учётные системы» как обобщение таких категорий ПО, как КИС (корпоративные информационные системы), АСУ, ERP, бухгалтерские, складские, логистические, банковские системы, в которых характерной чертой являются функции управления объектами учёта. Для учётных систем характерно то, что управление объектами учёта осуществляется пользователями, в соответствии с их бизнес-ролями и, соответственно, правами доступа. Конечно, возможны частные решения, когда некоторые манипуляции с объектами учёта производятся серверными (хранимыми) процедурами, но в конечном счёте события, влекущие активизацию этих процедур инициируются именно пользователями. В отличие, например, от АСУТП (MES), в которых события, инициирующие бизнес-процедуры, наступают помимо пользователей, например, по изменениям показаний датчиков. Впрочем, для АСУТП подобные подходы тоже вполне применимы, но это тема уже другой статьи.

Объекты учёта
Объекты учёта (бизнес-объекты) могут иметь очень разную природу с точки зрения проблемной среды. Для CRM-модуля это в первую очередь клиенты, в том числе потенциальные и их заказы. Для HR-модуля — сотрудники, позиции штатного расписания. Для складской системы — товарные партии и прочие единицы хранения. Объектами учёта могут являться как материальные объекты, так и процессы, и события. Предполагается, что каждый класс объектов учёта соответствует отдельной таблице в схеме базы данных.
Объекты учёта могут быть типизированы по разнообразным, заранее предопределённым типам. Так сотрудник может быть либо мужского, либо женского пола, клиент может быть либо физическим, либо юридическим лицом, а юридическое лицо в свою очередь может относиться к вполне определённой форме собственности и т.д.
В схеме БД типизация соответствует ссылке на справочник соответствующих типов.
Объект учёта может обладать определёнными статусами, как задаваемыемыми явно, так и наличием данных и их значений в определённых атрибутах (полях записи).Например «новый», «подтверждён», «утверждён», «завершён», «закрыт». Статусы используются для определения прав доступа к объекту, и, как следствие, к его месту в бизнес-процессе исполнения его жизненного цикла. То есть являются основой управления потоком работ (WorkFlow).
Отдельного внимания заслуживает статус типа «утверждён». Дело в том, что некоторые объекты учёта, например бюджетное назначение, требуют довольно сложной дисциплины согласования, выражающееся в форме наложения виз. Состав требуемых виз может в свою очередь зависить от других статусов или иных атрибутов. Например, то же бюджетное назначение может требовать разного состава виз в зависимости от суммы и принадлежности к статьи к бюджетному классификатору.
Учётная система может вести фискальную информацию по объектам учёта - историю их изменений. От минимальной (кто и когда создал и в последний раз изменял объект учёта) до полной детальной истории по изменению каждого атрибута, позволяющей не только выявить злоумышление, но и откатить состояние объекта учёта на нужный момент.

Диаграммы расширенной ER-нотации
В отличие от классической ER-нотации Ченя, я предлагаю формировать диаграмму из объектов («квадратиков») разных форм. Так на диаграмме будут различаться объекты учёта и справочники типов. Последние в свою очередь могут различаться по своему внутреннему устройству на линейные и иерархические. Отдельными формами могут быть представлены статусы и визы. Отдельным атрибутом объектов учёта может быть способ ведения фискальной информации. Точно так же от классических связей «один ко многим» и многие ко многим» можно перейти к гораздо более тонкому описанию связей, указывающих в первую очередь на их прикладной смысл, а не на способ размещения внешних ключей в таблицах. Например связь формы «виза» с формой «объект учёта» может указывать на условия обязательности наличия такой визы для конкретного объекта учёта. Возможно, для различных проектов могут потребоваться различные расширения. Но благодаря наличию универсального диаграммера, подбор наиболее адекватной проекту нотации не проблема.

диаграмма системы управления бизнесом

Так выглядит универсальный диаграммер и диаграммы в нём

Бизнес-процессы
Я предлагаю рассматривать бизнес-процессы как управление жизненным циклом объектов учёта. Соответственно описание бизнес-процесса — это сценарий жизненного цикла объекта учёта. Кто и что может/должен сделать с объектом учёта в зависимости от его статуса. Возможно, диаграммы описания бизнес-процессов как сценариев окажутся более громоздкими и менее наглядными, чем IDEF3 и EEPC, например, но в отличие от них они будут действительно однозначно описывать бизнес-процессы, что позволит на основе таких диаграмм автоматически генерировать прототип серверной логики и пользовательского интерфейса.

Управление правами доступа
Я предполагаю, что права доступа должны распределяться не только на уровне процедур, таблиц и их полей, но и на отдельные записи таблиц, то есть раздельно на каждый объект учёта определённого класса. Доступ к процедурам, таблицам и полям и так управляется любым SQL-сервером СУБД достаточно гибко механизмом грантования. А вот критерии прав доступа на каждую запись (объект учёта) могут быть весьма нетривиальными. Эти критерии можно разделить на относящиеся к авторству (оунерству, «владению») конкретным пользователем конкретной записи, и на относящиеся к значениям произвольных атрибутов записи.
В первом случае имеется в виду различие прав доступа в зависимости от отношения пользователя к «владельцу» записи — у его начальника, подчинённых, коллег по подразделению или иной группе. То есть начальник «владельца» записи может иметь больше прав на манипуляции с записью, чем, например, подчинённый, или вообще сотрудник другого подразделения.
Во втором случае имеется в виду, что права доступа на запись (объект учёта) имеющим значения атрибута «сумма» больше $1000 для пользователя с конкретной ролью (например, «менеджер по продажам») могут быть урезаны, по сравнению с записью, где значение атрибута «сумма» меньше $1000. Описание прав доступа так же предполагается посредством диаграмм специальной нотации, позволяющим автоматическую генерацию серверных (хранимых) процедур, вычисляющих соответствующие права доступа.

Автоматическая генерация
Я предполагаю, что прикладной проект учётной системы должен быть полностью описан набором диаграмм соответствующих нотаций. Из расширенной ER-нотации порождается схема базы данных — таблицы, соответсвующие объектам учёта и справочникам типов, таблицы статусов и виз, таблицы ведения фискальной информации, а также триггеры, сохраняющие целостность данных, в частности фиксирующие изменения объектов учёта в фискальных данных. Из диаграмм управления правами доступа порождаются хранимые процедуры, вычисляющие права доступа конкретного пользователя на каждое поле каждой записи запрашиваемого набора данных, и возвращающих запрошенный набор (за исключением записей, на которые у пользователя не оказалось никаких прав), сопровождаемый маской прав доступа (rwed-mask) на каждое поле каждой записи. Из диаграмм сценариев бизнес-процессов порождаются серверные процедуры, вычисляющие статус, в частности по составу имеющихся для каждого объекта учёта виз.
И (NB!) прототип диаграмм пользовательского интерфейса.
А вот сложные и нетиповые алгоритмы поддержки бизнес-логики приложения генерировать автоматически смысла нет — проще реализовать их вручную и привязать к триггеру или к кнопке на пользовательском интерфейсе.

автоматически сгенерированная система управления бизнес процессами

В этом тестовом приложении все формы и их элементы сгенерированы автоматически — ни одной строчки кода, написанного вручную.

Структура пользовательского интерфейса учётных систем
Современные RAD-системы (Delphi, PowerBuilder и другие) позволяют разработчику создавать пользовательский интерфейс (GUI) буквально как душе угодно. Но реально в каждом проекте устанавливается стандарт на пользовательский интерфейс хотя бы для сохранения стилистического единства. И это касается не только эстетики отображения элементов интерфейса, но их функционального поведения. Согласитесь, что странно выглядит продукт, в котором горячие клавиши, состав управляющих кнопок, чекбоксов и радиокнопок или реакция на клики мыши заряжены совершенно по-разному.
Я предположил, что состав пользовательского интерфейса может быть структурирован, и предлагаю такую структуризацию.
Заранее прошу прощения за, может быть, неблагозвучную терминологию.
1) Мэйнлет — список выбора объекта учёта определённого класса,
с набором управляющих кнопок read,new,delete,save
2) Детлет — форма, содержащая значения атрибутов выбранного
в списке выбора мэйнлета объекта учёта. Такие атрибуты, как
типы объекта учёта, задаются соответсвующими списками выбора -
лукапами (lookup). Кроме того, на детлете может быть задан
подчинённый мэйнлет — список выбора для объектов учёта,
подчинённых данному объекту учёта. Например заявки данного клиента.
3) Агрлет — форма, содержащая агрегатные (суммарные, средние,
максимальные или минимальные) значения определённых атрибутов
объекта учёта на выборке, заданной в списке выбора мэйнлета
4) Фильтлет — форма фильтрации выборки мэйнлета. Фильтлет состоит
из полей с отношением (<,>,=,~ и т.д.), лукапов фильтрации по типам
и подчинённых фильтлетов, в свою очередь фильтрующих состав лукапов.
Все элементы фильтлета могут быть наделены чекбоксами, указывающими
участвует ли данный элемент в фильтрации. Вместо чекбоксов могут
быть радиогруппы, указывающие какой из элементов участвуе в фильтрации,
предполагая, что участвовать может только один элемент из радиогруппы.
5) MMRлет (точно неблагозвучно :( , может «узлет» будет лучше? :) )
Элемент, управляющий много-множественной связью — привязкой.
Справа налево из одного списка в другой перекидываются строки при
привязывании подчинённых объектов учёта к главному, Слева направо -
при отвязывании. Или наоборот. Как больше понравится заказчику :)
6) Функлет — форма вызова процедуры. Её поля рассматриваются как параметры
вызываемой процедуры.
В общем случае все списки выбора могут быть реализованы различными элементами используемой среды разработки. Я пользуюсь Tcl/Tk, так что списки выбора могут быть представлены комбобоксами, листбоксами, тривью и иными, доступными в тулките или его расширениях. Один (с раскраской, переупорядочиванием и быстрым поиском по колонкам) я даже сам реализовал.
Любой из вышеприведённых элементов может быть размещён одним из
нижеперечисленных способов:
1) Отдельный фрейм. На той же форме, но в отдельной рамке
2) Закладка. Ну понятно… Впрочем, есть возможность размещать элементы
на общих закладках, а есть на специализированных. То есть для фильтлетов,
например, свой собственный набор закладок, для детлетов — свой, и т.д.
3) Локально перекрывающий фрейм. Это фрейм отрисовывается поверх того окна,
на котором размещена кнопка его вызова.
4) Глобально перекрывающий фрейм. Он отрисовывается поверх всего приложения.
5) Отдельное окно. С рамкой, крестиком, квадратиком… Ну то есть полноценное
окно с точки зрения операционной системы.
Понятно, что всё это многообразие в рамках одного проекта бессмысленно.
Но надо же как-то потрафить эстетическим предпочтениям заказчика.
Возникает вопрос — покрывает ли такая структуризация все мыслимые
решения для GUI учётных систем? Очевидно, нет. Всегда найдется заказчик, который захочет, чтоб, например, распределение статей бюджета велось непосредственно на «диаграмме пирога» (pieslice). Ну так недолго и вкрутить.
Возникает другой вопрос — сводима ли функциональность любого учётного приложения к такой структуре GUI? Наверное, да. А если что-то сводиться вдруг не захочет, лапами упрётся — ну так недолго и вкрутить, как я уже упоминал выше.

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

Автоматическая генерация vs кастомизация типовых решений
В своей статье «Золотой ключик» я развёрнуто проанализировал недостатки брэндовых программ для управления бизнесом на основе кастомизации наборов типовых решений. Но это не означает, что я в принципе против типовых решений. Более того, разрабатываемый мной инструментарий предусматривает коллекции типовых решений.
Но главное, это то, что набор типовых решений не подлежит кастомизации, а лишь служит прототипом для заказного решения, которое полностью создаётся под требования заказчика, а не мучительно под эти требования подгоняется путём наложения заплаточных частных решений слой за слоем. Ну и лицензионно-независимая платформа тоже даёт ряд преимуществ, по стоимости владения в первую очередь.

«Золотой ключик» системной интеграции

Сразу оговорюсь, речь идёт только об интеграции программных решений.
В «железе» я совершенно не компетентен и судить о проблемах интеграции аппаратного обеспечения не берусь.

Повторное использование кода: «не изобретать велосипед»
И действительно — зачем в 1001 раз писать собственный бухгалтерский модуль, если на рынке, кроме 1С, ещё полно самых разнообразных бухгалтерских программ. Или модуль для отдела кадров. Или управление складом…
Тезис о «неизобретении велосипеда» — основной конёк интеграторов. Мол, на каждую требуемую функциональность подберём для вас самый подходящий модуль от лучших производителей. Но тут кроется подвох.
На рынке действительно полно типовых программных решений, как в отдельных специализированных системах, так и  интегрированых в ERP-системы. Но! Спектр этих типовых решений как правило ограничен наиболее общеупотребимой функциональностью — то есть тем, что требуется практически каждой компании. Полно бухгалтерских, кадровых, CRM-систем, складских. Но найти что-нибудь подходящее за рамками этого «джентельменского» набора — очень проблематично. Попробуйте найти на рынке модуль планирования и оперативного управления сменно-суточного задания экспериментального цеха опытного производства, особенно под специфику применяемых технологий. Вы окажетесь глубоко разочарованы! Итак, главная проблема «неизобретательства велосипеда» в том, что все «велосипеды» типовые.
Применив типовое решение, вы отказываетесь от собственных конкурентных преимуществ во всех технологиях, и главное — в технологии управления. Вы покорно пристраиваетесь в хвост очереди на бизнес-успех. Зато у вас «типовой велосипед», сертифицированный по РСТ, ISO и т.д. И бизнес придётся вести по-типовому, в соответствии со стандартами управления, навязанными вам «лучшими поставщиками ПО».  Конечно, почти все производители типовых программных решений, особенно «лучшие производители», предлагающие типовые решения, интегрированные в ERP, заявляют об «открытости» решений, о возможности их функционального развития и модификации. Но по большому счёту это лукавство.

Реляционная модель VS предикативная — эффективность VS гибкость
Первая и главная трудность, с которой сталкивается тот наивный, кто поверил в «открытость» типовых решений «от лучших производителей» — это отказ от реляционной модели данных в пользу предикативной. Термин «предикативная модель» не общеупотребимый, я его использую на свой страх и риск, просто в силу моего математического образования :) . Мне довелось «покопаться в потрошках» нескольких систем, использующих предикативную модель вместо реляционной. Это наша 1С и не наши Axapta и OEBS (бывший Oracle Applications). Безусловно, предикативная модель обеспечивает гораздо большую гибкость. Можно, чуть ли не выходя из приложения, добавлять(удалять) поля данных.
Вот только зачем? Поспешность нужна при ловле блох, а вовсе не при проведении бизнес-реинжиниринга.
Декларируется, что такая гибкость обеспечивает снижение трудозатрат при внесении изменений в функциональность. А вот это уже не лукавство, а наглая ложь. Ну то есть, конечно, если понадобилось добавить поле данных, которое на самом деле на функциональность вообще никак не влияет (дополнительное поле комментария, например), то таки да. А ну как это самое дополнительное поле должно ещё как-то осмысленно обрабатываться и действительно менять поведение пользовательского интерфейса или серверных процедур? Тогда беда! Написать, а тем более отладить фрагмент кода, который шарится по таблицам предикативной модели, на порядок сложнее, чем, например, навесить триггер на нормальную реляционную таблицу. Не скажу про 1С, всё же наши писали, вменяемые российские программисты, а вот в Axapte и Oebs есть потаённые подвалы кода, в которые, как в тайную комнату Синей Бороды, вход если не запрещён, то сильно не рекомедуется. Я не шучу, а дословно цитирую из Programmers Guide по Axapte и Oebs.  То есть возможность модифицировать функциональность есть, но ответственность за работоспособность модификаций «лучшие поставщики» не берут на себя ни в каком объёме — даже правила внесения изменений, которые бы всё же гарантировали работоспособность, не публикуют. В Axapte, да и в Oebs, есть так называемые «слои функциональности». Так вот, предыдущие по отношению к последним релизам, особенно самые старые, первоначальные, давно не поддерживаются, и не осталось людей, которые знают, как и почему именно так они написаны. И функциональность новых версий привносят, не внося изменения в предыдущие «слои», а навешивая всё новые и новые слои заплаток. Что, конечно, отнюдь не повышает эффективность. Кстати, об эффективности. Самый простенький запрос на предикативной модели исполняется не в разы, а на порядки медленней, чем на реляционной. Так что незачем удивляться, что в ПО «от лучших поставщиков» какой-нибудь аналитический отчёт строится часами, даже на сверхмощных серверах.

Модульность — преимущество или недостаток?
В данном случае под модульностью я понимаю функциональную, а не программную модульность. И эффективность модульного программирования, как приёма построения архитектуры, под сомнение не ставлю. Итак, ниже речь идёт только о функциональной модульности.
Почему-то «лучшие поставщики» считают модульность безусловным преимуществом. Наверное, для эффективной лицензионной (ценовой) политики это так и есть — вы платите только за те модули, которые приобрели и используете.
Правда, по факту оказывается, что модули всё же не такие уж независимые, и некоторые вы всё равно вынуждены приобретать «в нагрузку» к тем, которые без них работать не смогут. Так что переговоры о комплектации приобретения решения, например от Axaptы, могут превратиться в увлекательнейший триллер :) .
Но вот преимущества функциональной модульности с точки зрения архитектуры программных решений лично у меня вызывают очень большие сомнения. Представьте себе некую учётную систему, построенную по принципам функциональной модульности. Например, построенную по принципам, изложенным  в статье «Аспекты учета в транспортной логистике«.
Лично я не могу себе представить адекватное функционирование любого из перечисленных модулей общего назначения не в связи с модулями управления транспорта и модулем управления грузами. Или в 1С. Могу себе представить некую настройку, в которой функции бухгалтерии не замыкаются на другие функциональные модули, и остаётся возможность вести проводки не в связи с движением учётных данных в других функциональных модулях. Это дыра. То есть всегда есть возможность сделать проводки по первичке, не учтённой в других модулях. Казалась бы, а что тут страшного?
Ничего. За исключением того, что «интеграция» оказалась дырявой. И денежкам всегда будет куда утекать мимо управленческого учёта бизнеса.
Ну и ещё раз об эффективности реализации. При построении архитектуры программных решений по принципам модульной функциональности, каждый модуль должен сохранять адекватную функциональность как для полностью автономной работы, так и для полной или частичной интегрированности с другими модулями системы. А это дополнительные проблемы как эффективности, так и надёжности реализации. Конечно, это проблемы «лучших поставщиков». Но судя по тому, как они с этим справляются, расплачиваться в конечном счёте приходится конечным пользователям. Извините за каламбур :) .

Проблемы обмена данными между разнородными приложениями
Как я уже констатировал выше, далеко не всегда удаётся найти приемлемое интегрированное решение «от лучших поставщиков». Более того, как правило, ключевые бизнес-функции, содержащие главные конкурентные преимущества, в типовых решениях или вовсе не находят отражения, или средствами используемой ERP-системы реализуются в рамках тех ограничений (порой очень жёстких), которые этими средствами накладываются. Вспомните о «подвалах Синей Бороды«, прежде чем на такое решитесь. Выход есть. Всегда. Даже если вас проглотил лев :) .
И этот выход — интеграция разнородных приложений. Я сам этим пользовался, как говорится: «плавали, знаем».
В частности, мне приходилось пристёгивать к моим приложениям управления транспортной логистикой и 1С бухгалтерию, и специализированные программы расчёта таможенных платежей (ТАКСА). Сталкивался с проблемами, решал их. Чем и хочу поделиться.
В зависимости от наличия возможностей внешнего взаимодействия тех или иных сторонних (по отношению к собственному проекту) программных систем, проблемы решаются по-разному. Наличие хорошо документированного программного интерфейса (API) позволяет программно вызывать стороннее приложение (точнее, его программное ядро, без пользовательского интерфейса) и передавать в него учётные данные, или наоборот, получать данные от него. Но наличие API, тем более хорошо документированного, к сожалению, очень большая редкость. Другой вариант — совместная работа с СУБД. Здесь камнем преткновения может стать предикативная модель данных, используемая сторонней системой. Не то, чтоб организовать доступ к ней было совсем невозможно. Но, во-первых, очень сложно, а, во-вторых, нет уверенности, что не зацепим что-то недокументированное, не окажемся в «запретной комнате Синей Бороды«.
Можно организовать обмен на уровне экспорта-импорта файлов. Как правило, такая возможность есть во всех системах. Но данные, оказавшиеся вне транзакционного поля — постоянная угроза разрушения целостности. Поясню. После того, как одна система экспортировала данные, она ничего не знает об их судьбе. Может, их просто потеряет нерадивый сисадмин, может быть, их по каким-либо причинам не сможет полностью или частично обработать система-адресат. То есть до получения ответа-квитанции об успехе/неуспехе обработки экспортированных данных, их вообще трогать нельзя, даже если вдруг выяснится, что они содержат ошибку или утратили актуальность (устарели). Это вам не репликационный сервер — всю такую «удалённую транзакцию» придётся поддерживать чуть ли не ручками, и не дай Бог, если ручки окажутся кривенькими — костей не собрать!

Сервис-ориентированная архитектура — полёт за облака
Лет 10 назад понятие SOA стало притчей во языцех — очередная «серебряная пуля» для решения всех проблем системной интеграции. Но что-то как и после каждой «серебряной пули» восторги поутихли. И причин тут несколько.
Первое, это то, что мотивы возникновения SOA не столько технические, сколько коммерческие. Удобно потреблять услуги некоего внешнего сервера в объёме, качеству и по цене согласованном в контракте и SLA (Service Level Agreement — соглашение об уровне сервиса). И многие «облачные» сервисы действительно могут эффективно использоваться приложениями. Например, сервис прогноза погоды может успешно использоваться системой управления ЖКХ на предмет управления отоплением или системой противодействия паводкам и лесным пожарам МЧС. Можно было бы создать сервисы по техническим расчётам для САПР, например расчёт прочности несущих конструкций. Но тут возникает сложность следующей природы. Для эффективного расчёта надо передавать на сервер огромные  массивы данных. А если хотите сэкономить на пересылке при корректировке данных — организовать их хранение на сервере. Кроме чисто технических аспектов нагрузки на линии связи и базу данных сервера, возникает проблема согласования протокола. Сервер должен принимать данные в строго оговоренном формате, а забота на переформатирование данных ложится на пользователя. Существуют вполне успешные попытки предоставления сервиса по хранению и обработке учётных данных для управления бизнесом. Но в свете откровений Сноудена, мне кажется, этот успех не будет шириться.
Итак, «облачные» сервисы это, конечно, хорошо, хотя и не беспроблемно. Хорошо, в первую очередь тем, что сервисы могут конкурировать, и у потребителя возникнет возможность выбора.
Но зачем создавать «облачные» сервисы для самого себя??? То есть если вы создаёте систему, зачем вам создавать и поддерживать собственные сервисы, если потреблять их будет только ваша же система? То есть зачем использовать SOA, если все сервисы не сторонние, а собственные? Кто бы объяснил? То есть я, конечно, читал и слышал много всяких объяснений, но ни одного вразумительного так и не попалось. Ведь SOA- это доведенный до абсурда, до абсолюта всех недостатков подход к функциональной модульности. Посудите сами — гораздо проще, а главное надёжней, организовать взаимодействие функциональных модулей по базе данных, реализовав общие триггеры, хранимые процедуры, пакеты хранимых процедур как в Oracle, наконец, чем искусственно преодолевать нагороженные барьеры инкапсуляции, обмениваясь немыслимыми объемами данных, которые и так лежат себе в БД и всегда доступны. Где уж тут «бесшовность» интеграции! А уж во что обойдётся бизнес-реинжиниринг — просто страшно подумать! Одно дело подкрутить хранимую процедуру и совсем уж другое — по-новой отлаживать протокол обмена сервисов. И BPEL тут не подмога: буквально, чтоб два байта переслать, на бипеле приходится ваять навороченную XML-структуру. А уж о том, чтоб на нём сервисы учётной системы реально обменивались данными — и речи быть не может!
Конечно, SOA имеет свои ниши. О некоторых, в связи с сервисом прогноза погоды, я уже упоминал. Можно ещё упомянуть о мультиагентных технология для организации B2B взимодействий. Но не использовать же её для корпоративной учётной системы, в самом деле!

Резюме:САПР для «велосипедов»
Итак, снова вопрос — стоит ли «изобретать велосипед»? Стоит, если вы хотите быть первым в гонке!
Собственно, на чём строится апология «неизобретательства велосипедов»? В первую очередь это чисто маркетинговый ход «лучших поставщиков»- типа, даже не думайте, что с нами можно конкурировать!
Второе — это неудачная примерка западных реалий на отечественную почву. На западе программист (особенно русский) — это очень высокооплачиваемый сотрудник. И продукты его труда стоят очень дорого. А какой-нибудь «аналитик HR-модуля» — низкооплачиваемый технический сотрудник. При таких реалиях конечно дешевле внедрить что-нибудь «от лучших поставщиков», чем создавать собственное оригинальное решение. У нас же всё ровно наоборот. «Аналитк ХХ-модуля» получает в разы больше, чем вполне приличный программист. А если учесть затраты на приобретения лицензий на ПО «от лучших поставщиков», то окажется, что за такие деньги всю внедряемую функциональность можно реализовать с нуля под индивидуальный заказ, безо всяких системных интеграторов.
Ну и третье — это сроки разработки и надёжность эксплуатации и сопровождения. Да, увы, это реальные проблемы. Но их можно и нужно решать, а не отказываться от нового в пользу устаревшего типового. Устаревшего не в том смысле, что на наш рынок попадает только старьё-берьё, а в том, что развитие бизнеса требует постоянного обновления решений, и заказанное системным интегратором решение «под ключ» устаревает ещё до внедрения в опытную эксплуатацию. Кстати, упомянутая мной проблема сроков-надёжности- сопровождения в равной мере относится и к решениям от «лучших поставщиков». Только для них всегда наготове отмазка:»А что вы хотите? Мы же лучшие, лучше вам уж никто не предложит!».
Итак, как же быть? А очень просто! Ничто не ново под Луной! Когда-то люди добывали огонь трением и кодили в машинных кодах :) . В уме проектировали таблицы распределения памяти, таблицы переходов по циклам и обращения к подпрограммам. Потом появился Фортран, который все эти распределения вычислял сам. Когда-то и таблицы баз данных люди прописывали на DDL-SQL, пока не появился ER-WIN и S-Designer (ныне PowerDesigner), которые по нажатию волшебной кнопки Generate порождали все DDL-скрипты со всеми Create Table, Create Index и т.д. А потом и вовсе попёрло, как из рога изобилия: Delphi, C-Builder, PowerBuilder — то есть RAD-технологии встали на крыло.
Суть в том, что самые рутинные операции, требующие наибольших трудозатрат в смысле плющенья клавиш, автоматизируются проще всего. Просто понятие «исходный код» обретает всё более высокий уровень. И, если сначала это был действительно просто машинный код (нули и единички), потом тексты на языках высокого уровня, а там глядишь к понятию «исходники» будет относиться только набор диаграмм, полностью и однозначно описывающих структуру и функциональность учётного приложения.
Особое, самое почётное место среди RAD-систем занимал Oracle-Designer под Oracle-7. Он объединял возможности и ER-диаграммера, и Forms, и Reports. Поколдовав над диаграммами в разных нотациях, можно было получить готовый полнофункциональный рабочий прототип, просто нажав волшебную кнопку Generate. Непонятно только, почему в 8-ом и более поздних Ораклах от всего этого отказались? Может, не хотели конкуренции для своего Oebs (тогда ещё Oracle Applications)?
Но прогресс не остановить такими гнусными инсинуациями! :) Даёшь RAD-ERP! :)
И, в заключение, о названии этой статьи. Недаром в него вошло название культового произведения А.Толстого, также именуемого «Приключения Буратино». Просто уж больно системные интеграторы вкупе с «лучшими поставщиками» зачастую похожи на бессмертных персонажей этого бессмертного произведения — Лису Алису и Кота Базилио. Ну а заказчики системной интеграции «под ключ» — соответственного самого Буратино, закапывающего свои золотые на Поле Чудес в Стране Дураков :) .

Аспекты учета в транспортной логистике

Аспекты учета в транспортной логистике (2LP)
Транспортная логистика как бизнес весьма многогранна.
Наряду с общими для практически всех видов бизнеса функциональными модулями такими, как бухгалтерия, кадры, CRM/PRM, и функциональными модулями транспортными (управление автохозяйством), особый интерес представляют аспекты учёта собственно транспортной логистики: управление перевозками, таможенное оформление, консолидация и т.п.
Я буду рассматривать аспекты собственно транспортной логистики и общих функциональных модулей в связи с транспортно-экспедиторской деятельностью, оставив управление автохозяйством за кадром.

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

В бухгалтерском модуле информация о начале и завершении хозяйственных операций транспортной логистики должна появляться автоматически сразу по факту регистрации их в модулях транспортной логистики. И, соответственно, информация о регистрации соответствующих проводок в бухгалтерском модуле должна быть доступна в транспортно-логистическом немедленно. Совершенно недопустима ситуация, когда в разных функциональных модулях осуществляется повторный ввод данных или в результате экспорта-импорта данных между модулями образуется временной лаг в несколько часов или даже суток. Это неизбежно ведёт к рассинхронизации данных. И дело даже не в самих временных задержках, а в принятых пользователями решениях, основанных на неполной, устаревшей информации. Такие решения могут быть не только не оптимальными, не адекватными, но главное — разрушать логическую целостность данных, что ведёт к каскадному накоплению ошибок в учётной системе. Впрочем, об интеграции функциональных модулей я, пожалуй, напишу в отдельной статье.

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

Модуль CRM (управление отношениями с заказчиками) связан с транспортно- логистическим модулем историей заказов клиентов и их выполнения, претензиями, историей взаиморасчётов. Очень важный аспект — возможность вычисления прогноза новых заказов данного клиента и состава его грузов, в частности, в разрезе кодов ТНВЭД или иных классификаторов грузов/товаров.

Модуль PRM (управление отношениями с поставщиками, в данном случае — сторонними перевозчиками) связан историей выполненных перевозок и взаиморасчётов.

Модуль финансового контроллинга сильно связан со всеми модулями, поскольку сама система управленческого учёта строится именно на базе модуля финансового контроллинга. В его функции входит планирование и прогнозирование доходов, планирование и контроль расходов (бюджетирование), формирование аналитических данных для принятия решений о развитии бизнеса. Контроль расходов — это в первую очередь проверка обоснованности принятых решений о производимых расходах, а также процедура согласования и визирования таких решений. Поскольку процедура согласования и визирования принимаемых решений может касаться не только финансовых вопросов (например, подготовки документов для таможенного оформления), целесообразно выделить программную реализацию такой процедуры в отдельный модуль.

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

Модуль управления движением транспорта предназначен для планирования и контроля движения транспорта по складам в целях своевременной погрузки/разгрузки предназначенных для перевозки грузов. Критериями планирования является обеспечение заявленной срочности и условий перевозки грузов (ADR, терморежим и т.д.), а так же оптимизация себестоимости перевозки за счёт эффективной консолидации грузов и описанной выше оптимизации стоимости таможенного оформления. Оптимизация движения транспорта за счёт централизованного выбора маршрута в зависимости от дорожных условий (погода, пробки, состояние покрытия) представляется пока малоэффективной в силу сложностей сбора и актуализации таких данных по маршруту движения, а главное в их непредсказуемости — даже используя сервис «Московские пробки» план на 6-8 часов может оказаться абсолютно неадекватным. А уж кто где в Европе забастует, или где в России перекопают магистраль — непредсказуемо абсолютно.
Контроль движения транспорта может осуществляться прямыми (телефонными) контактами с водителем/экспедитором либо спутниковой системой слежения как периодически (к концу дня), так и по контрольным точкам маршрута (склады консолидации, погранпереходы, СВХ и т.д.).

Модуль управления движением груза предназначен для планирования и учёта фактической разгрузки/погрузки предназначенных для перевозки и/или хранения грузов. Данный модуль функционально сильно связан с модулем управления движения транспортом в первую очередь контролем целостности Ньютонова пространства и соблюдения принципа Дирихле: ни что не может одновременно находиться более чем в одной точке. Кстати, отсутствие такого контроля во многих системах управления транспортной логистикой является источником постоянных ошибок пользователя — планируется (и регистрируется) погрузка груза на транспорт на складе, даже если транспорт и груз, который на него грузится, находятся на совершенно разных складах!
Кроме того, данные модуля управления движением груза используются для оптимизации движения транспорта и наоборот — данные модуля управления движением транспорта используются для оптимизации движения груза. Но это зависит от принятой в конкретной транспортно-логистической компании технологии управления вообще. Ещё одной функцией данного модуля является контроль соблюдения условий хранения и первозки грузов — суммарное ограничение по весу и объёму груза на транспорте, ADR, терморежим и т.д.
Отдельно стоит задача маркировки и идентификации грузов, включая в том числе и палетированные грузы. Для маркировки могут использоваться шильдики со штрих-кодом или иные более современные средства. Кроме того, транспортное средство может сопровождаться схемой или даже фото размещения груза в нём. Задача оптимального размещения груза методами динамического программирования пока остаётся маловостребованной из-за множества плохо формализуемых и малопредсказуемых факторов, значимых для загрузки. Как правило, на месте опытные грузчики лучше справляются с этой задачей, чем централизованная система управления погрузкой, требующая учёта множества факторов, многие из которых по халатности пользователей или неполноты предоставленной владельцем груза информации своевременно заданы не были.

В данной статье я рассмотрел ряд значимых аспектов учёта в транспортной логистике.
Этот ряд заведомо не исчерпывающий. Каждый владелец и/или руководитель бизнеса стремится добиться конкурентного преимущества в частности за счёт оптимизации управления.
И это приводит к тому, что различные транспортно-логистические компании предъявляют к учётным системам различные, иногда прямо противоположные требования в зависимости от технологии ведения своего бизнеса. Для разных компаний разные аспекты имеют разную значимость и детальность, и, как следствие, требуют различной реализации всех вышеупомянутых и иных специальных модулей. Более того, бизнес-реинжиниринг в конкретной компании может приводить к очень сильным изменениям требований к учётной системе.
Резюмируя констатирую: самым постоянным требованием к учётной системе является обеспечение непостоянности (развития) остальных требований. :) )

Со всеми удобствами…

Удобно ли, когда замок входной двери сам защёлкивается? Казалось бы да.

Не надо лишний раз лезть за ключом, когда выходишь. Но лишний ли?

Вспомните историю инженера Щукина из 12 стульев. А самим в подобном

положении не доводилось оказаться? Такова цена удобств…

Казалось бы, причём тут Лужков? Ой, я имел в виду учётные системы :)

 предлагаемые по умолчанию данные

Умолчания

Как удобно, когда система сама предлагает пользователю данные, решения, целые фрагменты текста. Остаётся только кликнуть на ОК! Но!

Если бы предлагаемые по умолчанию данные, решения, фрагменты не требовали, кроме нажатия ОК, никаких других действий, то система вполне могла бы хотя бы в этом месте обойтись без пользователя вообще. То, что пользователь должен на ОК кликнуть, означает, что он готов взять на себя ответственность за подтверждение предлагаемых системой данных. Но тут возникает вопрос — а какова цена этих «удобств»? Экономим нажатие кнопок?

Экономим на крохах, теряем на ворохах.

Смысл подтверждения именно во взятии ответственности. Если пользователь, убаюканный «удобствами», не удосужился задуматься над тем, что он подтверждает, то что мы сэкономили? Так может пусть он ручками забьет требуемые данные или хотя бы осознанно (без предлагаемого умолчания) выберет их из списка. И никакие дополнительнительные  «А Вы действительно уверены?» не помогут — их он перещёлкнет ещё более автоматически.

Цена ошибки — жизнь.

Мне доводилось разрабатывать банковские системы. Заказчик ясно понимал цену ошибки. В начале 90-х или в общении с Юкосом это вполне могла быть жизнь. От меня сознательно требовали отсутствия  всяких умолчаний. И даже повторного ввода данных, как при подтверждении пароля. Так спрашивается, а что, цена ошибки в других учётных системах снизилась настолько, что пользователя держат просто клавиши плющить? Последние годы мне чаще приходилось разрабатывать учётные системы в других областях бизнеса. Заказчик не так щепетильно относился к защите от ошибок. «Поставьте здесь по умолчанию такое-то значение, как правило требуется именно оно». А потом с удивлением обнаруживается, что пользователи, особенно начинающие, даже не удосуживаются взглянуть на соответствие умолчания реальным требованиям учёта. И все данные остаются по умолчанию, хотя это явно ошибочно.

«Как правило»… А ну как исключение? Как правило, я тоже из дому выходил, проверив наличия ключа…

Редактирование

Наученный высокими требованиями «защиты от дурака» в банковских системах, я взял за правило открывать отдельную форму создания/редактирования любой учётной записи.

  • Во-первых, пользователь имеет возможность увидеть без всякого скролирования (прокрутки), перелистывания все данные, на основе которых он должен принять решение.
  • Во-вторых, он точно знает, что данные сохранятся по кнопке «Сохранить» и в любой момент до этого он может данные исправить или вообще отказаться от операции.

«А нам удобно редактировать прямо в гриде (ячейках таблицы)». Удобно  так удобно. Потом оказывается, что в таблице, которую разом на экране не разместишь (требуется прокрутка), через раз просто промахиваются мимо строки. А главное, не понимают, в какой момент сохраняются данные. Когда переходят на другую ячейку? Или строку? Или вообще закрывают форму? И бегут к администратору БД – исправьте, пожалуйста, мы тут ошиблись. Ну как, удобно вам???

О модальности экранных форм

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

«Модальные формы нарушают права человека!» В смысле пользователя.

Типа, надоело в этой форме работать, открою-ка я другую, может там поинтересней окажется. Вот, собственно, такое право безответственного скакания с формы на форму и ограничивают. Учётная система — это не портал развлекательных сайтов. Сюда люди приходят работать. Но я это пишу не для того, чтоб поморализировать или защитить права работодателя от прав работника. Не завершив регистрацию учётных данных в одной форме, пользователь может открыть и начать работать в другой, которая содержит данные, логически связанные с незакрытой. Или, пройдя по меню, оказаться в той же форме, но, естественно, в новом её экземпляре. С новым экземпляром данных. И самое ужасное, что с  тем же самым, редактирование которого он не закончил на предыдущей открытой. А дальше конфликт неизбежен. Программно защитить данные от разрушения при параллельном редактировании их в разных формах — не вопрос. Вопрос в том, понимает ли пользователь, какой вариант редакции данных в конечном счёте окажется в базе.

Ответ — безусловно нет. Так и не надо его на подобные ошибки провоцировать! А чтоб пользователю не надо было искать необходимую информацию на других формах системы, формы надо проектировать так, чтоб вся необходимая для принятия решений информация была у него перед глазами в данной форме. Ну максимум — на закладках или всплывающих окнах данной формы. Кстати, такой подход к модальности открывает прямой путь к созданию WorkFlow — управлению работой пользователя. Когда система если не управляет, то хотя бы направляет пользователя к выполнению тех операций в учётной системе, которые от него требуются в данный момент.

Хотелось поделиться ещё соображениями об удобстве уже не пользовательском, а разработческом. О тех же умолчаниях, слабой типизации, инкапсуляции-полиморфизме-наследовании. Но, пожалуй, в следующий раз.

Проблемы описания бизнес-процессов

Подходы

Понятие «бизнес-процесс» — многогранное, и, как следствие, существует множество подходов к описанию бизнес-процессов, воплощающихся в различных нотациях.

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

Документный подход –

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

Оторванность от природы предметной области — это одновременно и достоинство этого подхода и недостаток. Недостаток состоит, в первую очередь, в том, что реинжиниринг даже отдельных участков бизнеса влечет за собой радикальное изменение состава документов и их жизненных циклов, и, как следствие, требует переписывание многих описаний бизнес-процессов и создание основанной на них программной системы почти с нуля. Достоинством же является наличие на рынке большого числа оболочек программных систем, ориентированных на документный подход, таких как 1С и Navision, значительно снижающих трудозатраты на разработку прикладного ПО. Кроме того, привычная и хорошо формализованная терминология документного подхода упрощает проектное обследование (интервьюирование, согласование) по сравнению с подходами, требующими более высокого уровня абстракции.

Ресурсный подход –

восходит к ERP-системам. Его особенностью является взгляд на предметную область как на набор ресурсов и бизнес-процессов, преобразующих ресурсы.

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

Поточный подход –

предлагает взгляд на бизнес-процессы, как на потоки работ (заданий) исполнителей.

Можно сказать, что это наиболее процессно-ориентированный подход, и в той или иной мере он отражен практически во всех применяемых для описания бизнес-процессов нотациях. Его преимуществом является наглядность, а недостатком – то, что вне фокуса оказываются важные детали, связанные с преобразованием учетных данных.

Датацентристский подход –

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

Суть подхода заключается в выделении в модели объектов учета специальных объектов типа «процесс», обладающих обязательным набором атрибутов (время начала/конца, исполнитель) и связями с объектами, которыми данный процесс манипулирует.

«ДОступный» подход –

основывается на описании прав доступа исполнителей к объектам модели учета.

В конечном счете, все, что исполнитель в какой-то момент может сделать с объектом учета, именно это он _должен_ сделать.

Совместимость описаний

Уровни детализации: декомпозиция и агрегирование.

Очевидно, что в зависимости от назначения описания бизнес-процессов, требования к детализации совершенно различные.

«Большому боссу» требуется картина «крупными мазками». В его понимании бизнес-процессы – это скорее направления бизнеса, чем реальные процессы, привязанные к временной шкале. Стрелки, изображаемые на диаграммах бизнес-процессов этого уровня детализации, служат исключительно эстетическим целям и никаких реальных связей не отражают. Для тим-лидера кодеров наоборот требуется максимальная детализация описаний – кто в какой момент какие манипуляции может и/или должен совершить. Между этими граничными (минимальным и максимальным) уровнями детализации лежит целый спектр уровней детализации, который используется аналитиком для согласования требований заказчика на разных уровнях организационной структуры.

Множественность нотаций

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

Это позволяет компенсировать недостатки одних нотаций достоинствами других и выбирать для интервьюирования эксперта наиболее адекватную его образу мышления нотацию.

Обеспечение совместимости

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

В качестве минимальной меры обеспечения совместимости предлагается введение регламентов, требующие от аналитика соблюдать некоторые формальные правила при переходе от одного уровня детализации к другому и от одной нотации к другой. Однако в силу семантической неоднозначности (омонимии) ныне применяемых нотаций (IDEF0,IDEF3,EPC), такие правила либо не общезначимы, либо настолько громоздки, что сами служат источником ошибок. Программная поддержка таких правил могла бы развиваться в двух направлениях – программный контроль полноты и непротиворечивости описаний и автоматизация генерации прототипа описания в иной нотации или на ином уровне детализации. Очевидно, что прототип, порожденный для более детального уровня с менее детального (в частности само описание на менее детальном уровне) требует доработки вручную. Возникает соображение, что обратное преобразование (с более детального на менее) может быть произведено автоматически. Однако это соображение весьма сомнительно, поскольку правила агрегирования в таком случае должны различать (или порождать) основные элементы от детальных. Особый интерес представляет объектно-ориентированная программная поддержка, обеспечивающая инкапсуляцию на каждом уровне детализации элементов описания в разных нотациях и множественное наследование различных типовых решений.

Предложение

Предлагается применить датацентристский и «доступный» подходы для описания нотации, основанной на состояниях объектов учета, переходах между состояниями и агентах переходов.

Приводимые ниже рассуждения строятся «снизу-вверх», однако, поддержанные программным механизмом автоматизации декомпозиции, могут использоваться при описании бизнес-процессов в обратном направлении («сверху-вниз»).

Классом объектов учета будем называть некоторую выделенную сущность (база класса) и произвольную совокупность сущностей, связанных с базой, в том числе и опосредованно. Объектом будем называть элемент базы в совокупности со всеми связанными элементами всех сущностей класса. Состояние объекта определяется некоторым предикатом над выделенным набором атрибутов всех сущностей класса и, возможно, значениями предикатов других состояний данного объекта. Таким образом, каждый объект может находиться или не находиться в некоторых состояниях. В общем случае объект может находиться более чем в одном состоянии, но возможно включить в предикат состояния предикаты всех остальных состояний, если потребуется единственность состояния объекта в каждый момент. Построим ориентированный граф, вершинами которого будут являться состояния, а ребрами – допустимые переходы из одного состояния в другое. Припишем каждому ребру роли (совокупности ролей). Не вдаваясь в прочие технические детали, полученный граф будет являться описанием бизнес-процессов, преобразующим модель данных в соответствии с правами доступа пользователей.

Представляется возможным на основании предложенной нотации породить более традиционные – IDEF, EPC, USE-CASE, WorkFlow и т.п. А главное, наряду со схемой базы данных, из описания бизнес-процесса в такой нотации можно сгенерировать прототипы экранных форм пользовательского интерфейса.