Информационная экономика - мост в будущее - 4
продолжение - 4 часть
Взгляд изнутри
Приступим к описанию внутреннего механизма проектируемой системы. Параллельно с изложением будут даваться ссылки на образец - систему ЭИСС-ИСС (система субконтрактации г. Санкт-Питербург), в конце статьи есть перечень источников, из которых можно будет познакомиться с ней более детально [3] [1]. Но заметим опять, что будет использована общая с ней необходимая для сельско-городских коопераций функциональность, проигнорировано то, что к ним не относится и добавлены новые весьма существенные компоненты.
Общее информационное пространство и активная сеть
Соединение участников виртуального предприятия в активную сеть не может произойти само по себе. Для этого требуется организационный и информационный фундамент, на базе которого и происходит это соединение. Группа авторов «Реинжиниринга бизнес-процессов проектирования и производства» С-Петербургского университета информатики [3] обозначила его как «межорганизационный потенциал отношений или информационно-управленческую среду». Эта информационная среда должна быть устроена таким образом, чтобы постоянно активизировать кооперации, предоставлять участникам виртуального предприятия Заказы и обеспечивать работу всей системы. Потенциал отношений формируется за счет работы организаций, заинтересованных в создании виртуального предприятия координирующим центром. Для проектируемой системы таким координирующим центром будет выступать для части коопераций заказчик системы, а так же будет предоставлена возможность самостоятельного кооперирования любым составам участников (возможность «самоорганизации») с выделением ими «центра-координатора».
Подчеркивается [3], что « в начальной фазе много времени уходит на поиск подходящих партнеров, построение межчеловеческих отношений, а также на развитие общего видения ситуации». Приводится ссылка на статистику, «подготовительной фазы кооперирования», на которую падает до 30% расходов, причем указывается, что «многие кооперации распадаются, так и не возникнув». Виртуальное предприятие возникает тогда, «когда на базе созданной информационно-управленческой среды постоянно формируются ориентированные на заказы, временно ограниченные активные сети». При этом «число партнеров в информационно-управленческой среде должно быть намного больше, чем в активной сети, что приводит к новым конфигурациям деятельности специалистов предприятий».
Чтобы приступить к детализации этого интегрированного информационного пространства. и выделить первые, его самые крупные блоки, покажем бизнес процесс, происходящий внутри системы. Для этого вернемся к описанию процесса коопераций (см. выше «Создаем кооперацию») и развернем его более подробно.
Как видно из рисунка единое информационное пространство разбивается на две большие области: это активная сеть, в которой формируются виртуальные предприятия и торговая площадка. Их сумма и образует общую информационно-управленческую среду. Обе области функционально связанны друг с другом, но имеют возможность работать автономно. Предприятия, входящие в систему и регистрирующиеся в качестве Клиентов, могут образовывать активные сети, и входить в неограниченное количество виртуальных предприятий (под активной сетью понимается подмножество Клиентов сети, работающих в виртуальных предприятиях или другими словами сумма этих виртуальных предприятий). Но, в то же время, каждый Клиент системы может реализовать готовую продукцию через электронную торговую площадку, без участия в виртуальном предприятии. Сразу подчеркнем, что в отличие от системы субконрактации, где торговая площадка работает как нечто «пристегнутое», как дополнительный сервис, торговая площадка проектируемой системы, входит в «ядро» системы и обладает ключевой возможностью, предоставленной и «виртуалам» - предоставлять Клиентам возможность оптимизации торговой операции. Так же сделаем акцент, что эта возможность, даже в «стартовом», небольшом диапазоне возможностей (далее будут кратко перечислены способы оптимизации), - радикальный шаг, меняющий ранее применявшиеся стратегии маркетинга продукции. Основные новации будут лежать в наиболее чувствительной сфере, связанной с ценообразованием.
[0] - [1]
Бизнес процессы будут происходить между стрелками, изображенными на рисунке. Переход от одной стрелки к другой показывают изменение состояния объектов системы. Система существует в реальном экономическом окружении из производителей, физических лиц, потребителей. Они находятся вне системы, но могут зарегистрироваться в качестве ее участников или Клиентов. Причина: или размещение Заказа, или желание участвовать в виртуальном предприятии, либо совершать торговые операции на электронной торговой площадке. Этот процесс показан переходом от стрелки (0) к стрелке (1). Регистрация Клиента на первом этапе имеет своей целью не просто ввести его реквизиты, но главное - ввести данные по его основным компетенциям, состоянии загруженности производства и данные по спросу предложению (грубо говоря - прайс лист). Даже этот первый шаг несет много непростых моментов, часть которых необходимо решать сразу, а более сложные оставлять как «заглушку». Один из них - это ввод ролей клиентов системы. Но основной состоит в том, как стандартизировать вводимую информацию для дальнейшей обработки. Дело в том, что все данные должны как минимум идентифицированы (поиск), а лучше - сравнимы между собой (алгоритмы оптимизации). Наиболее реальный путь - применение системы идентификации налоговой службы, классификаций Госстатистики и международных классификаций. Но даже для этих относительно простых операций необходимо решить массу вопросов. Классификаторы госстатистики создавались первоначально для макроэкономического анализа и поэтому для бизнеса они совершенно не годятся. Они - неудобны, избыточны и имеют массу пересечений для одних и тех же товаров (к примеру, одна и та же позиция пшеницы упоминается в классификаторе ОКП несколько раз). Классификаторы отечественные и международные должны быть гармонизированы (то есть должно быть введено соответствие между позициями этих классификаций), но опять же - это сделано не для всех необходимых. И главный фундаментальный порок - они не приспособлены для позиционирования товаров по качеству. Для этого необходимы классификаторы совершенно другой природы. Скажем сразу, что практика торговых площадок для госзакупок, где формализация данных имеет первостепенное значение, выработала подходы для сглаживания острых углов. Эти подходы будут использованы и в проектируемой системе. Но для позиционирования товара по качеству будет предложен новый, ранее нигде не применявшийся классификатор, решающий проблему формализации данных и работы оптимизационных алгоритмов.
[1] - [2]
Далее масса зарегистрированных предприятий (и физических лиц) может сообразно размещенному Заказу образовать активную сеть, образуя виртуальное предприятие. Этот момент, исходя из экономических реалий, должен проектироваться максимально гибко. Крайние его точки: первая - полностью автоматизированное создание виртуального предприятия для выполнения заказа, крайняя точка - ручной индивидуальный подбор потенциально возможных участников и поиск заказа вне системы. Рассмотрим их по порядку, поскольку этот и следующий процесс составляет сердцевину системы.
* Инициатор - заказчик. Оптимизатор находит для заказчика варианты готовых виртуальных предприятий (то есть перечень координационных центров). Для этого необходимо, чтобы в заказе были указаны все необходимые условия поставки (номенклатура, объемы, цены, качество, сроки и проч.). Для координационных центров необходимо параллельно с этим выставить возможности производства этих или аналогичных товаров, а так же условия реализации заказа. При совпадении данных с обеих сторон (не обязательно 100%) - выводится список вариантов с обоснованием выбора. После согласования с заказчиком и оформления отношений начинается процесс производства;
** Инициатор - координационный центр. Оптимизатор находит заказы и предлагает их варианты координационному центру имеющего свое виртуальное предприятие. После выбора необходимого и согласования с заказчиком, оформления отношений начинается процесс производства;
*** Инициатор - координационный центр или предприятие. Оптимизатор находит заказы и предлагает их варианты координационному центру не имеющего виртуального предприятия. В случае выбора выгодного заказа, координационный центр создает свое виртуальное предприятие и согласовывает условия поставки с заказчиком и участниками виртуальной сети (этот вариант показан стрелкой обратно направленной от (2) к (1));
**** Инициатор - координационный центр или предприятие. Координационный центр ищет заказ вне системы, создает свое виртуальное предприятие и согласовывает условия поставки с потенциальным заказчиком и участниками виртуальной сети (этот вариант показан стрелкой обратно направленной от (2) к (0)). Для этого необходимо, что бы потенциальный заказчик стал зарегистрированным участником системы.
Из приведенного бизнес-процесса вытекает необходимость: структурирования данных для обработки оптимизатором, проектирование математического алгоритма оптимизации, а так же возможность работы в «ручном» режиме для создания виртуальных предприятий, согласовывая интересы в интерактивном режиме.
Для взаимодействия участников сети нужна выработка правил: прав и обязанностей. Они необходимы для элементарной регламентации работы, а так же разрешения неизбежных конфликтов. В одну из обязанностей будет входить поддержание в актуальном состоянии данных, характеризующих участника сети. В противном случае он автоматически будет заблокирован, а затем удален из системы. Важным условием так же будет являться стандартизация и порядок обмена сообщениями, проходящими между участниками при их взаимодействии.
[2] - [3]
После согласования условий работы трех сторон: заказчиком, координирующим центром и участниками виртуального предприятия, - запускается процесс реализации Заказа. При этом «координирующему центру» необходимо синхронизировать работу всех производителей, по объемам, порядку поставок в цепочке и срокам и производить процесс управления. Эта задача как указывалось ранее крайне не простая именно для специфики агарного бизнеса. Основная сложность состоит в том, что кооперационные цепочки не сводятся к стандартной схеме: один заказчик - несколько субподрядчиков (как в субконтрактации), и поэтому не могут все закрыться одним-двумя типовыми процессами. Использование сложных и дорогих автоматизированных ERP комплексов, закрывающих вопрос (которые являются частью ЭИСС- ИСС системы) невозможно, да и бессмысленно, для мелких и средних предприятий агробизнеа. Масса бизнес процессов там не сложна, и основная проблема состоит только в их разнообразии и оперативной адаптации. Необходимо простое и доступное решение.
Как оказалось оно существует. Развитие техник моделирования бизнес-процессов, дали несколько превосходных инструментов, позволяющих решить эту сложную задачу. Решение состоит в применении инструментов моделирования «третьего поколения» (ERP системы относятся ко второму поколению). Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System) и дает возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью [7]. А она не требуют разработки дополнительного программного обеспечения. Для разработки понятных машине «исполняемых» моделей требуются более точные методы моделирования. Для этого были разработаны методы средства конвертирования графических моделей бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели бизнес-процессов с использованием графической нотации, а затем преобразовывать построенную модель в исполняемый вид. Стандарты и общие технологии поддерживает такая замечательная организация как OMG (Object Management Group), являющаяся к тому же и автором стандартов UML - языка проектирования информационных систем. Существуют как коммерческие, так и свободно распространяемые продукты автоматизирующие все стороны бизнес процессов: от построения диаграмм, разработки организационной структуры, до внедрения документооборота и инструментов планирования ресурсов. Последний пункт как раз и востребован в первую очередь.
Резюмируя, можно сказать, что это именно наш вариант. На практике проектирования системы это будет означать следующее. Для нескольких наиболее типовых бизнес процессов будут создан «пакет» наборов прикладных экранных форм. Они позволят участникам планировать работу, согласовывать действия, вводить данные виртуального предприятия и отслеживать создание, перемещение, состояние производственных ресурсов (с/х сырья и продуктов). Для агро бизнеса это неизмеримо проще чем для высокотехнологичных производств, требующих работы с электронными чертежами (PDM системы). К примеру, наиболее типовой может рассматриваться, как организация нескольких мелких поставщиков и владельцев транспорта для формирования мелкооптовых партий и поставке заказчику. Вся функциональность будет урезана до самой необходимой. В случае если возникнет необходимость создать софт на более высоком детализированном уровне или для нестандартных коопераций - возможна их проектирование и генерация по индивидуальному заказу.
[3] - [4]
Этот процесс граничит между активной сетью виртуального предприятия и торговой площадкой. Возможны два варианта.
Первый. Он показан стрелкой (4)-(1). Здесь готовая продукция выдается заказчику, - для большинства случаев это такое же предприятие и производятся взаиморасчеты (то есть бизнес ведется преимущественно внутри «производственной сферы»). Для задачи автоматизации взаиморасчётов можно создать массу сервисов, но этого для стартовой версии программы делать нецелесообразно, поскольку значительные для разработки средства здесь будут использованы с минимальной отдачей. Как сказал руководитель крупной лизинговой компании на мое замечание, о важности автоматизации расчётно--бухгалтерских функций: «Ты дай мне заработать, а считать я их заставлю на калькуляторах». Необходимо предоставить для начала ключевой учетный сервис (счета, договора, и проч.) без инструментов их создания и генерации.
Второй. Он возникает в случае, когда продукция не имеет своего заказчика, а ищет его после процесса производства: в этом товар поступает на электронную торговую площадку. Ее работа показана в следующем бизнес-процессе (4) -(5).
[4] - [5]
Гарантированный сбыт продукции для агропроизводства по оптимальным ценам и в «свое время» не просто важно - по большому счету это «все» что нужно агробизнесу. Ни копеечные субсидии и дотации, ни слабое и неэффективное вмешательство с целью «регулирования» рынка ни прочие инициативы МСХ - все это для руководителя агрохозяйства малоинтересно. Ему необходимо не просто произвести, но главное - оптимально сбыть. Именно вокруг этой коллизии и должен вращается весь механизм госуправления агроотраслью в плане экономики и бизнеса, но, к сожалению, пока это получается «не очень». Поэтому включение электронной площадки, которая едва ли не вдвое увеличивает объем программирования - должно иметь веские основания и они оправдываются именно этим пунктом.
Процесс сбыта продукции через электронную торговую площадку конечному потребителю так же предусматривает два варианта: первый - реализация потребителю, находящемуся вне системы и не зарегистрированной в нем (5). Второй - закрытие размещенного в системе заказа имеющейся готовой продукцией (5)- (1).
Центральный элемент системы электронной площадки представлен электронным магазином. Его функциональность включает, прежде всего, размещение товара (предложение), а так же потребностей в товарах и услугах. Этот момент нестандартен для прочих электронных площадок и объясняется унификацией всей системы, в которой необходимо и подыскивать клиентов по компетенциям (выраженных в требованиях [-]) и по наличию готовой продукции [+]. Далее размещенный на витрине товар может быть приобретен клиентом системы. Клиент системы может быть и зарегистрированным предприятием и просто физическим лицом первый раз посещающим сайт. В этом плане все стандартно и копирует массу известных электронных магазинов: «витрины», «корзины», «заказы», счета, доставку и все остальное. Однако кроме всего этого, в магазине проектируются мощные возможности оптимизации, ранее системно нигде не применявшиеся. Они пока состоят из трех возможностей: оптимизировать сделку по
= объему продукции: «объем-цены» (розница, опт). Ее смысл в использовании шкалы скидок;
= качеству продукции: «качество-цены» . Реализована методом позиционирования продукта по качеству, используя классификатор качества;
= логистике: «цена- логистика». Учитывает расчёты оптимальных транспортных путей.
Необходимо отметить, что перечисленные выше методы торговой оптимизации, имеют значительную практику, разбросанную по многочисленным торговым площадкам, различных отраслевых сегментов. В проектируемой системе они унифицированы и «вшиты» в индивидуальные настройки Агентов.
Исходя из объемов программирования все сервисы могут вводиться последовательно, один за другим.
Добавим, что для автоматизации двух последних процессов (3)-(4), (4)-(5) необходимо в дальнейшем использовать имеющиеся на рынке продукты автоматизации бухучета. В техническом плане это не составит особых сложностей - вопрос только в целесообразности применения, исходя из их стоимости.
окончание 5 часть
Взгляд изнутри
Приступим к описанию внутреннего механизма проектируемой системы. Параллельно с изложением будут даваться ссылки на образец - систему ЭИСС-ИСС (система субконтрактации г. Санкт-Питербург), в конце статьи есть перечень источников, из которых можно будет познакомиться с ней более детально [3] [1]. Но заметим опять, что будет использована общая с ней необходимая для сельско-городских коопераций функциональность, проигнорировано то, что к ним не относится и добавлены новые весьма существенные компоненты.
Общее информационное пространство и активная сеть
Соединение участников виртуального предприятия в активную сеть не может произойти само по себе. Для этого требуется организационный и информационный фундамент, на базе которого и происходит это соединение. Группа авторов «Реинжиниринга бизнес-процессов проектирования и производства» С-Петербургского университета информатики [3] обозначила его как «межорганизационный потенциал отношений или информационно-управленческую среду». Эта информационная среда должна быть устроена таким образом, чтобы постоянно активизировать кооперации, предоставлять участникам виртуального предприятия Заказы и обеспечивать работу всей системы. Потенциал отношений формируется за счет работы организаций, заинтересованных в создании виртуального предприятия координирующим центром. Для проектируемой системы таким координирующим центром будет выступать для части коопераций заказчик системы, а так же будет предоставлена возможность самостоятельного кооперирования любым составам участников (возможность «самоорганизации») с выделением ими «центра-координатора».
Подчеркивается [3], что « в начальной фазе много времени уходит на поиск подходящих партнеров, построение межчеловеческих отношений, а также на развитие общего видения ситуации». Приводится ссылка на статистику, «подготовительной фазы кооперирования», на которую падает до 30% расходов, причем указывается, что «многие кооперации распадаются, так и не возникнув». Виртуальное предприятие возникает тогда, «когда на базе созданной информационно-управленческой среды постоянно формируются ориентированные на заказы, временно ограниченные активные сети». При этом «число партнеров в информационно-управленческой среде должно быть намного больше, чем в активной сети, что приводит к новым конфигурациям деятельности специалистов предприятий».
Чтобы приступить к детализации этого интегрированного информационного пространства. и выделить первые, его самые крупные блоки, покажем бизнес процесс, происходящий внутри системы. Для этого вернемся к описанию процесса коопераций (см. выше «Создаем кооперацию») и развернем его более подробно.
Как видно из рисунка единое информационное пространство разбивается на две большие области: это активная сеть, в которой формируются виртуальные предприятия и торговая площадка. Их сумма и образует общую информационно-управленческую среду. Обе области функционально связанны друг с другом, но имеют возможность работать автономно. Предприятия, входящие в систему и регистрирующиеся в качестве Клиентов, могут образовывать активные сети, и входить в неограниченное количество виртуальных предприятий (под активной сетью понимается подмножество Клиентов сети, работающих в виртуальных предприятиях или другими словами сумма этих виртуальных предприятий). Но, в то же время, каждый Клиент системы может реализовать готовую продукцию через электронную торговую площадку, без участия в виртуальном предприятии. Сразу подчеркнем, что в отличие от системы субконрактации, где торговая площадка работает как нечто «пристегнутое», как дополнительный сервис, торговая площадка проектируемой системы, входит в «ядро» системы и обладает ключевой возможностью, предоставленной и «виртуалам» - предоставлять Клиентам возможность оптимизации торговой операции. Так же сделаем акцент, что эта возможность, даже в «стартовом», небольшом диапазоне возможностей (далее будут кратко перечислены способы оптимизации), - радикальный шаг, меняющий ранее применявшиеся стратегии маркетинга продукции. Основные новации будут лежать в наиболее чувствительной сфере, связанной с ценообразованием.
[0] - [1]
Бизнес процессы будут происходить между стрелками, изображенными на рисунке. Переход от одной стрелки к другой показывают изменение состояния объектов системы. Система существует в реальном экономическом окружении из производителей, физических лиц, потребителей. Они находятся вне системы, но могут зарегистрироваться в качестве ее участников или Клиентов. Причина: или размещение Заказа, или желание участвовать в виртуальном предприятии, либо совершать торговые операции на электронной торговой площадке. Этот процесс показан переходом от стрелки (0) к стрелке (1). Регистрация Клиента на первом этапе имеет своей целью не просто ввести его реквизиты, но главное - ввести данные по его основным компетенциям, состоянии загруженности производства и данные по спросу предложению (грубо говоря - прайс лист). Даже этот первый шаг несет много непростых моментов, часть которых необходимо решать сразу, а более сложные оставлять как «заглушку». Один из них - это ввод ролей клиентов системы. Но основной состоит в том, как стандартизировать вводимую информацию для дальнейшей обработки. Дело в том, что все данные должны как минимум идентифицированы (поиск), а лучше - сравнимы между собой (алгоритмы оптимизации). Наиболее реальный путь - применение системы идентификации налоговой службы, классификаций Госстатистики и международных классификаций. Но даже для этих относительно простых операций необходимо решить массу вопросов. Классификаторы госстатистики создавались первоначально для макроэкономического анализа и поэтому для бизнеса они совершенно не годятся. Они - неудобны, избыточны и имеют массу пересечений для одних и тех же товаров (к примеру, одна и та же позиция пшеницы упоминается в классификаторе ОКП несколько раз). Классификаторы отечественные и международные должны быть гармонизированы (то есть должно быть введено соответствие между позициями этих классификаций), но опять же - это сделано не для всех необходимых. И главный фундаментальный порок - они не приспособлены для позиционирования товаров по качеству. Для этого необходимы классификаторы совершенно другой природы. Скажем сразу, что практика торговых площадок для госзакупок, где формализация данных имеет первостепенное значение, выработала подходы для сглаживания острых углов. Эти подходы будут использованы и в проектируемой системе. Но для позиционирования товара по качеству будет предложен новый, ранее нигде не применявшийся классификатор, решающий проблему формализации данных и работы оптимизационных алгоритмов.
[1] - [2]
Далее масса зарегистрированных предприятий (и физических лиц) может сообразно размещенному Заказу образовать активную сеть, образуя виртуальное предприятие. Этот момент, исходя из экономических реалий, должен проектироваться максимально гибко. Крайние его точки: первая - полностью автоматизированное создание виртуального предприятия для выполнения заказа, крайняя точка - ручной индивидуальный подбор потенциально возможных участников и поиск заказа вне системы. Рассмотрим их по порядку, поскольку этот и следующий процесс составляет сердцевину системы.
* Инициатор - заказчик. Оптимизатор находит для заказчика варианты готовых виртуальных предприятий (то есть перечень координационных центров). Для этого необходимо, чтобы в заказе были указаны все необходимые условия поставки (номенклатура, объемы, цены, качество, сроки и проч.). Для координационных центров необходимо параллельно с этим выставить возможности производства этих или аналогичных товаров, а так же условия реализации заказа. При совпадении данных с обеих сторон (не обязательно 100%) - выводится список вариантов с обоснованием выбора. После согласования с заказчиком и оформления отношений начинается процесс производства;
** Инициатор - координационный центр. Оптимизатор находит заказы и предлагает их варианты координационному центру имеющего свое виртуальное предприятие. После выбора необходимого и согласования с заказчиком, оформления отношений начинается процесс производства;
*** Инициатор - координационный центр или предприятие. Оптимизатор находит заказы и предлагает их варианты координационному центру не имеющего виртуального предприятия. В случае выбора выгодного заказа, координационный центр создает свое виртуальное предприятие и согласовывает условия поставки с заказчиком и участниками виртуальной сети (этот вариант показан стрелкой обратно направленной от (2) к (1));
**** Инициатор - координационный центр или предприятие. Координационный центр ищет заказ вне системы, создает свое виртуальное предприятие и согласовывает условия поставки с потенциальным заказчиком и участниками виртуальной сети (этот вариант показан стрелкой обратно направленной от (2) к (0)). Для этого необходимо, что бы потенциальный заказчик стал зарегистрированным участником системы.
Из приведенного бизнес-процесса вытекает необходимость: структурирования данных для обработки оптимизатором, проектирование математического алгоритма оптимизации, а так же возможность работы в «ручном» режиме для создания виртуальных предприятий, согласовывая интересы в интерактивном режиме.
Для взаимодействия участников сети нужна выработка правил: прав и обязанностей. Они необходимы для элементарной регламентации работы, а так же разрешения неизбежных конфликтов. В одну из обязанностей будет входить поддержание в актуальном состоянии данных, характеризующих участника сети. В противном случае он автоматически будет заблокирован, а затем удален из системы. Важным условием так же будет являться стандартизация и порядок обмена сообщениями, проходящими между участниками при их взаимодействии.
[2] - [3]
После согласования условий работы трех сторон: заказчиком, координирующим центром и участниками виртуального предприятия, - запускается процесс реализации Заказа. При этом «координирующему центру» необходимо синхронизировать работу всех производителей, по объемам, порядку поставок в цепочке и срокам и производить процесс управления. Эта задача как указывалось ранее крайне не простая именно для специфики агарного бизнеса. Основная сложность состоит в том, что кооперационные цепочки не сводятся к стандартной схеме: один заказчик - несколько субподрядчиков (как в субконтрактации), и поэтому не могут все закрыться одним-двумя типовыми процессами. Использование сложных и дорогих автоматизированных ERP комплексов, закрывающих вопрос (которые являются частью ЭИСС- ИСС системы) невозможно, да и бессмысленно, для мелких и средних предприятий агробизнеа. Масса бизнес процессов там не сложна, и основная проблема состоит только в их разнообразии и оперативной адаптации. Необходимо простое и доступное решение.
Как оказалось оно существует. Развитие техник моделирования бизнес-процессов, дали несколько превосходных инструментов, позволяющих решить эту сложную задачу. Решение состоит в применении инструментов моделирования «третьего поколения» (ERP системы относятся ко второму поколению). Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System) и дает возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью [7]. А она не требуют разработки дополнительного программного обеспечения. Для разработки понятных машине «исполняемых» моделей требуются более точные методы моделирования. Для этого были разработаны методы средства конвертирования графических моделей бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру строить модели бизнес-процессов с использованием графической нотации, а затем преобразовывать построенную модель в исполняемый вид. Стандарты и общие технологии поддерживает такая замечательная организация как OMG (Object Management Group), являющаяся к тому же и автором стандартов UML - языка проектирования информационных систем. Существуют как коммерческие, так и свободно распространяемые продукты автоматизирующие все стороны бизнес процессов: от построения диаграмм, разработки организационной структуры, до внедрения документооборота и инструментов планирования ресурсов. Последний пункт как раз и востребован в первую очередь.
Резюмируя, можно сказать, что это именно наш вариант. На практике проектирования системы это будет означать следующее. Для нескольких наиболее типовых бизнес процессов будут создан «пакет» наборов прикладных экранных форм. Они позволят участникам планировать работу, согласовывать действия, вводить данные виртуального предприятия и отслеживать создание, перемещение, состояние производственных ресурсов (с/х сырья и продуктов). Для агро бизнеса это неизмеримо проще чем для высокотехнологичных производств, требующих работы с электронными чертежами (PDM системы). К примеру, наиболее типовой может рассматриваться, как организация нескольких мелких поставщиков и владельцев транспорта для формирования мелкооптовых партий и поставке заказчику. Вся функциональность будет урезана до самой необходимой. В случае если возникнет необходимость создать софт на более высоком детализированном уровне или для нестандартных коопераций - возможна их проектирование и генерация по индивидуальному заказу.
[3] - [4]
Этот процесс граничит между активной сетью виртуального предприятия и торговой площадкой. Возможны два варианта.
Первый. Он показан стрелкой (4)-(1). Здесь готовая продукция выдается заказчику, - для большинства случаев это такое же предприятие и производятся взаиморасчеты (то есть бизнес ведется преимущественно внутри «производственной сферы»). Для задачи автоматизации взаиморасчётов можно создать массу сервисов, но этого для стартовой версии программы делать нецелесообразно, поскольку значительные для разработки средства здесь будут использованы с минимальной отдачей. Как сказал руководитель крупной лизинговой компании на мое замечание, о важности автоматизации расчётно--бухгалтерских функций: «Ты дай мне заработать, а считать я их заставлю на калькуляторах». Необходимо предоставить для начала ключевой учетный сервис (счета, договора, и проч.) без инструментов их создания и генерации.
Второй. Он возникает в случае, когда продукция не имеет своего заказчика, а ищет его после процесса производства: в этом товар поступает на электронную торговую площадку. Ее работа показана в следующем бизнес-процессе (4) -(5).
[4] - [5]
Гарантированный сбыт продукции для агропроизводства по оптимальным ценам и в «свое время» не просто важно - по большому счету это «все» что нужно агробизнесу. Ни копеечные субсидии и дотации, ни слабое и неэффективное вмешательство с целью «регулирования» рынка ни прочие инициативы МСХ - все это для руководителя агрохозяйства малоинтересно. Ему необходимо не просто произвести, но главное - оптимально сбыть. Именно вокруг этой коллизии и должен вращается весь механизм госуправления агроотраслью в плане экономики и бизнеса, но, к сожалению, пока это получается «не очень». Поэтому включение электронной площадки, которая едва ли не вдвое увеличивает объем программирования - должно иметь веские основания и они оправдываются именно этим пунктом.
Процесс сбыта продукции через электронную торговую площадку конечному потребителю так же предусматривает два варианта: первый - реализация потребителю, находящемуся вне системы и не зарегистрированной в нем (5). Второй - закрытие размещенного в системе заказа имеющейся готовой продукцией (5)- (1).
Центральный элемент системы электронной площадки представлен электронным магазином. Его функциональность включает, прежде всего, размещение товара (предложение), а так же потребностей в товарах и услугах. Этот момент нестандартен для прочих электронных площадок и объясняется унификацией всей системы, в которой необходимо и подыскивать клиентов по компетенциям (выраженных в требованиях [-]) и по наличию готовой продукции [+]. Далее размещенный на витрине товар может быть приобретен клиентом системы. Клиент системы может быть и зарегистрированным предприятием и просто физическим лицом первый раз посещающим сайт. В этом плане все стандартно и копирует массу известных электронных магазинов: «витрины», «корзины», «заказы», счета, доставку и все остальное. Однако кроме всего этого, в магазине проектируются мощные возможности оптимизации, ранее системно нигде не применявшиеся. Они пока состоят из трех возможностей: оптимизировать сделку по
= объему продукции: «объем-цены» (розница, опт). Ее смысл в использовании шкалы скидок;
= качеству продукции: «качество-цены» . Реализована методом позиционирования продукта по качеству, используя классификатор качества;
= логистике: «цена- логистика». Учитывает расчёты оптимальных транспортных путей.
Необходимо отметить, что перечисленные выше методы торговой оптимизации, имеют значительную практику, разбросанную по многочисленным торговым площадкам, различных отраслевых сегментов. В проектируемой системе они унифицированы и «вшиты» в индивидуальные настройки Агентов.
Исходя из объемов программирования все сервисы могут вводиться последовательно, один за другим.
Добавим, что для автоматизации двух последних процессов (3)-(4), (4)-(5) необходимо в дальнейшем использовать имеющиеся на рынке продукты автоматизации бухучета. В техническом плане это не составит особых сложностей - вопрос только в целесообразности применения, исходя из их стоимости.
окончание 5 часть