Леопольд Офигевшие посторонниеПо состоянию на начало мая 2006 года в этой системе настроено под 200 бизнес процессов Бизнесс-процессы -
это совершенно не то , что подразумевают под ними разработчики it-предприятия.
Вот это интуиция! практически все спорные вопросы подняты.
Вы совершенно правы - бизнес процессов на самом деле гораздо меньше, или гораздо больше - в зависимости от того, считать вариацию БП отдельным БП или нет.
Постараюсь ответить, как сам понимаю (ИМХО).
В описании ЛЮБОГО БП присутствует "точка неустойчивости" (аттрактор в терминологии "теории катастроф") - это точки входа (выхода) БП. На самом деле - очень сложно определить, где заканчивается один БП, и начинается другой.
Возьмем элементарный процесс оплаты С/ф (облиго), пример:
Отдел сбыта регистрирует в системе С/ф поставщика, Начальник отдела визирует, финансовый контролер проверяет цены, финансовый отдел оплачивает, бухгалтерия обрабатывает оплаченные счета и подшивает в пачку(формирует архив).
Вроде все понятно но:
1.При внесении счета может существовать или нет, быть разовым или долговременным договор с поставщиком. Более того, к договору могут существовать несколько спецификаций, исполнение которых может (или нет) отслеживаться "до позиций" - нужна связь между строками спецификации и строками счета.
2. Появлению счета предшествовал определенный процесс - на поставщика выставлялось предложение, он выставлял свое, согласовывались цены, объемы поставки (из-за "кратности поставки" часть количества может покупаться в "запас на склад" т.е. под личную ответственность отдела закупок)
и все это надо (или нет) отражать в системе.
3.Счет тоже возник не на "пустом месте" - в начале была потребность, причем она (потребность) сборная. Часть взята из "заявок подразделений" - свой БП связанный вдобавок с бюджетом, часть - из потребности производства - громадный кусок планирования с календарными графиками. С/ф должна содержать информацию о источнике потребности - планы производства могут меняться, бюджет подразделения может быть сокращен (или расширен) - не нужные счета не должны оплачиваться.
4.При оплате тоже возникают отклонения - счет может быть оплачен на 50% или на сколько денег было, оплата может "не пройти по банку" и т.д.
5.При приходе материала возможны возникновения "замен" - к моменту оплаты изменилась номенклатура (у поставщика) или потребность (у заказчика) - это необходимо отслеживать.
Попытка описать (и это "Грубо") БП - привела "комбинаторной" степени сложности вариантов. Для описания взаимосвязи БП (а именно в них находится "суть") понадобится НАСТОЯЩАЯ "сеть Петри"- с альтернативами, "стоячими волнами" (срок действия счета 3 дня - не уплатили надо брат новый и начинать процесс заново) и прочими "прелестями".
К тому же, один БП (много их плодить нельзя финотдел не разберется) должен иметь разную степень детализации - если покупаем авторучку, процесс должен быть радикально упрощен, а если устраиваем тендер - надо отслеживать все итерации.
Попытка реализовать БП - "как нарисовано" погубила не одну хорошую идею - просто все варианты одного процесса либо нельзя описать (ограничение системы), либо нельзя понять (ограничение пользователя), а тем, что можно ввести и понять - нельзя пользоваться, любая новая ситуация приводит к "затыку".
Как преодолеваем:
1.Из общего бизнес процесса выделяются прямые цепочки операций см.п1-5 (каждый п. сам по себе такой процесс).
2.На "точках принятия решения" - из одного процесса порождается следующий
3.Взаимодействие между процессами настраивается отдельно.
Фактически - такое решение проблемы было найдено задолго до появления компьютеров, это - бюрократический документооборот. Каждый документ движется по своему пути обработки (опред. типом документа) по пути на нем проставляются "визы" или от него порождаются новые документы, что отображает процесс принятия решений.
Пример: Счет передан на оплату в финотдел - на основании счета (или нескольких счетов) - генерируется новый документ - платежное поручение. Оба документа хранят память о событии, но в дальнейшем обрабатываются отдельно - ПП пойдет через клиент банк, затем (по подтв. оплаты) будет использовано для создания дебиторской задолженности (если аванс) или покрытия кредиторской. Счет (счета) послужит образцом для прихода - по нему будут отслеживать разницу между заявкой и приходом (если есть).
При этом, количество документов у предприятия ограниченно (но велико) в отличии от вариантов их комбинации,- ведь вместо оплаты может быть передан(выпущен) вексель, осуществлен зачет и т.д.
Под "типом процесса" разработчики it-предприятия подразумевают элементы находящиеся
"на уровень ниже" чем БП. Это - первичные документы предприятия.
p.s. OLAP - в системе есть подсистема позволяющая строить и редактировать кубы. Просто оперативные отчеты оказались настолько эффективны, что ее внедрение все откладывают "на потом".
FlareА у вас есть в наличии для вашей системы в документации схемы данных (data model diagrams, тоесть данные о таблицах и связях между ними) и схемы бизнес процессов (business process maps, вот вроде такого) к примеру?
"таблицы и связи между ними" - из системы
ОПИСЫВАЮТСЯ , тамже можно описать виртуальные таблицы (view), индексы и т.д. Соответственно - можно и посмотреть (если стандартного Enterprise Manager мало).
Про "процессы" написал раньше. Для каждого "типа процесса" - визуализатор есть, но "табличная" форма (ИМХО) - удобней.
p.s. Я сильно сомневаюсь, что построенная схема взята "из системы ERP" (а не построена в visio) и будет меняться при изменении настроек ERP-системы автоматически.
p.p.s. С "чужими" БП сделанными "за большие деньги" имел дело неоднократно - в качестве входных шаблонов для системы... Даже жизнено-важные (для данного бизнеса) вопросы - вроде "оплаты векселем", "зачета", "передачи акций (или пая)", "товарного кредита", "благотворительности" оказываются забыты :-(
