Ув. Владислав Жаринов.
Как Вы уже, возможно, успели заметить, мне приходится заниматься программированием этих бизнес-процессов, будь они неладны. Попробую поделиться и своими пятью копейками.
Жизнь заставила описание процессов привести к относительно простой и универсальной модели. Упрощённо ее можно представить в виде нескольких таблиц или списков:
- бизнес-модули
- регистры информации и субрегистры
- балансовые единицы
- бизнес-объекты
- бизнес-участки
- группы пользователей или роли
- список пользователей
Слово-паразит "бизнес-..." лично мне не нравится, но так исторически попсово повлиял "ынтырпрайз". Подробнее:
- бизнес-модули - это список решаемых или выполняемых "бизнес-задач". В рамках представленного учебного задания здесь можно указать "Расчёт бюджета проекта по поставке продукции ...", также можно добавить "Учёт материальных запасов", "Расчёты с поставщиками", "Управление покупателями", а при необходимости можно развернуть весь состав деятельности предприятия от бухгалтерии до управления. Структура списка, т.е. состав полей, пока не важен, сейчас достаточно наименования модуля, ну и кода, к примеру;
- регистры - в первом приближении, это списки типов или видов документов, которые прикреплены к каждому бизнес-модулю. Т.е. для бизнес-модуля "расчёт бюджета ..." указывается, что в его рамках ведутся документы: "договор, форма такая-то" для отношений с поставщиками, "договор ..." для клиентов, "спецификация проекта, форма..." и т.д. Для "учёта материальных запасов": "акт приёмки ...", "накладная отгрузки" и т.д. Структура документов может быть тоже раскрыта в отдельных описаниях, сейчас этот момент опускаем;
- субрегистры - это некая вариантная часть регистра. К примеру, для "спецификации проекта" можно отдельно выделить "привязанные" бухгалтерские проводки и проч. реквизиты, если это предусмотрено. И, таким образом, как бы, для "обслуживания" документа явно предопределяется два этапа: оформление или создание спецификации и её проведение в бухгалтерии. Можно добавить ещё один "субрегистр" - "одобрямс" от начальника, и тогда бухгалтерия "займётся" документом после "подписи" ответственного начальника. Или, к примеру, для "акта приёмки товаров" можно выделить два субрегистра: первый -цены и суммы, второй - реквизиты поставщика. Тогда, например, складской работник имеет только количественные данные, кто-то другой может и "подбивать суммы", а кто-то имеет полный доступ к документу, включая "коммерческую тайну" - реального поставщика. В общем, о нюансах сущности субрегистров будет ещё сказано.
Кроме того, регистры - это универсальное понятие, это не только реальные первичные (внешние и внутренние) документы, это и справочные массивы данных, и различные режимы работы, действия в рамках программной системы. Формально, каждый "чих" в прогкомплексе оформляется документально, пусть и несколько абстрактно. Если кто-то запустил какой-то расчёт данных (т.е. "выполнил" какой-то "регистр" с учётом варианта-субрегистра), то это всё фиксируется, и можно выписать справку, кто и когда что именно сделал.
Таким образом, через регистры и их опции - субрегистры - раскрывается сущность бизнес-модуля, т.е. указывается, какая осуществляется деятельность;
- балансовые единицы - это список "владельцев" бизнес-модулей, т.е. это "хозяева". В системе их может быть несколько, они повязаны между собой, возможен консолидированный учёт. Скажем, головное предприятие и дочерние, предприятие может через кучу частных предпринимателей осуществлять "поставку продукции", в конце концов, возможна "чёрная бухгалтерия" и т.д.;
- бизнес-объекты - это объекты аналитического учёта. Например, в рамках "расчёта бюджета проекта ..." мы можем захотеть вести учёт в разрезе групп клиентов, кому-то поручить одну группу, другой исполнитель обслуживает иных клиентов и т.д. Группировать можно в зависимости от потребностей: VIP-клиенты, резиденты/нерезиденты, распределить их по алфавиту и т.п. Таким образом, мы можем выделить бизнес-объекты -- "Группы клиентов". В рамках смежного бизнес-модуля "материальный учёт" можно указать "подразделения предприятия" (как склады, к примеру) в качестве бизнес-объектов;
- бизнес-участки - это аналитические участки бизнес-деятельности предприятия. Например, создаём участок №36 "Обслуживание клиентов ...", где указываем, какая деятельность выполняется - составляем список используемых регистров данных (т.е. документов и действий нужных бизнес-модулей), к примеру, все регистры из "расчёт бюджета..." и часть регистров из "материального учёта", "прикрепляем" к участку группу клиентов в рамках регистров "расчёт бюджета" и несколько складов в рамках "учёта материалов". При этом согласно структуре управления предприятием никакого подразделения №36 "Обслуживание клиентов ..." нет, это некое виртуальное определение в разрезе информационного учёта. А вот в этом участке №36 косвенно задействованы реальные подразделения предприятия: склад №12, склад №16 и к нему (бизнес-участку) будут "привязаны" некоторые работники этих складов, а также представители отдела маркетинга и финотдела. Можем создать ещё один похожий участок №37, где укажем другую группу клиентов, и, возможно другие склады и т.п.
Иными словами, вся деятельность предприятия (а точнее, та, которая "автоматизирована") ведется только через бизнес-участки (в информационном плане). Каждый участок привязан к нужной балансовой единице (участок может "входить" только в одну балансовую единицу), для каждого участка указывается список деятельности - регистры из нужных бизнес-модулей, и к каждому участку привязываются бизнес-объекты в рамках соответствующих регистров. При этом один и тот же бизнес-объект не может быть привязан к одному и тому же регистру дважды. Например, если склад №12 мы привязали к регистрам материального учёта на участке №36, то этот склад больше нигде не может быть прикреплён к материальному учёту, но в рамках расчёта зарплаты он может быть указан на другом участке (или на том же №36);
- роль - группа пользователей, которые выполняют одни и те же действия. Составляется список ролей, каждой роли назначаются права: указывается, к какому бизнес-участку имеется доступ, к каким его регистрам и их субрегистрам, а также с какими бизнес-объектами возможна работа на участке. При этом для регистров задаются права для выполнения операций чтения документа или выполнения (если это действие/режим), редактирования и удаления, а также чтение/выполнение связанных субрегистров. Таким образом, через права пользователей есть возможность задать, кроме списка допустимых действий, косвенно и порядок работ по исполнителям. К примеру, создают какой-то документ те, кто имеет на это право, только после создания документа специалист по экономическим вопросам может проставить в нём цены и суммы, затем начальник поставит свою подпись, и только потом бухгалтерия его может акцептировать.
Роли в программной системе не обязательно те должности, которые указаны в штатном расписании. Скажем, на фирме, где всего-лишь директор и бухгалтер да кладовщик, роль менеджера по подготовке спецификации заказа может исполнять бухгалтер, а его деятельность в рамках бухучёта может быть и не отражена в комплексе;
- список пользователей - это состав конкретных пользователей. Каждому пользователю даются права определенной роли, причём только одной. Если нескольких пользователей привязали к одной роли, то все они могут заниматься одним и тем же, но в системе все действия пользователя (т.е. все его документы, включая виртуальные) подписываются его конкретным именем. Если исполнитель Вася уволился и на его место пришёл Петя, то достаточно Пете быстро назначить нужную роль.
В общем, это довольно упрощённое представление, старался описать попроще, надеюсь, что более-менее понятно. Опущены ряд свойств, скажем, в системе могут быть указаны конфигурационные параметры в разных разрезах, например, какой-то коэффициент для ценообразования может быть задан разный для каждого участка (для клиентов разных групп - разные скидки, и т.п.). В зависимости от настроек определяется состав программного рабочего места, интерфейс для работы с документами, вид отчётов и т.д и т.п.
Вся модель задаётся в виде таблиц. Что касается граф-схем. Мою историю с рисованием Вы уже знаете. Имхо, в 90 процентах случаев после составления этих табличек в схемах потребности, реальной, нет. Модель, конечно, составляется не сразу, циклически, с разборами полётов, после ряда этапов разработки и т.д. Более того, ситуация такова. От меня и моих коллег, как представителей небольшой компании-разработчика всяких автоматизированных систем, не всегда (а точнее, редко) требуют блок-схемы в рамках документации к комплексу. Как правило, их всё-равно никто не смотрит толком, да и документацию не читают тоже, одни формальности. Теоретически, наоборот, нам должны выдавать схемы в рамках технического задания, и я, откровенно говоря, что-то не помню, чтобы нам какие-то "бизнес-описатели" давали реально полезную схему, одна "бизнес-вода". Схемки приходится иногда составлять для разборов полётов, причём полёт устраиваем мы, поэтому приходится выжимать максимум реально возможного и, прежде всего, полезного из графического представления, и Вы уже смогли заметить, под какую горячую руку попал ДРАКОН. В принципе, если бы была адекватная технология создания схем, при этом схемы интегрированы с остальной документацией, а то и с программным кодом (некий ГРАФИТ-ФЛОКС), то я не исключаю, что в практике схем было бы больше, а то и всё бы документировалось, как и требуется. Вот сейчас оцениваются на эту роль Р-схемы.
А в рамках представленной учебной задачи (я просмотрел текст по диагонали), я бы, для себя, набросал бы схемку общего процесса, где показал бы, что происходит, начиная от обращения клиента, как на него реагируют, какие и когда ведутся документы (спецификации проекта, отгрузки) и т.д. и т.п. Сначала без исполнителей, т.е. определил бы состав "регистров", с чувством, какие намечаются "бизнес-участки", и т.д. Есть потребность раскрыть ряд расчётов, например, методику ценообразования.
А схемы деятельности для одного исполнителя по мотивам как выше в постах: в цикле ждать события, а в фоне при отсутствии событий заниматься такими-то обязанностями или курить в сторонке - имхо, слабо полезны. Тем более, в реальной жизни он эту инструкцию "будет нарушать" беспрерывно, в фоновом цикле, так сказать
. Исполнитель разберётся, когда ему покажут его список "регистров".