Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


  

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

Д. Л. Казанский

Автоматизация производственного предприятия и внедрение на нем ERP-системы (Enterprise Resource Planning, подробнее об этом см.: Сети и системы связи. 1998. № 2. С. 30) требуют большой предварительной работы. В частности, она заключается в изучении с формальных позиций всех автоматизируемых процессов. Поэтому здесь уместно считать, что предприятие — это система, которая трансформирует входящий поток договоров, заказов и заявок в выходной поток услуг, товаров, изделий при наличии дополнительных ограничений, таких, как доступные ресурсы и технологии, регламент взаимоотношений с государством, внутренняя структура предприятия и пр. Для простоты все формы запросов из внешнего мира будем называть заказами.

Бизнес-функции

Бизнес-функции (БФ) — это элементарные кванты действия, активности. Минимально нормируемые и оцениваемые действия. БФ образуют функциональный базис для всех технологических и административно-хозяйственных процедур на предприятии. Природа БФ — административная или технологическая — при формализации задачи не имеет особого значения. Важно, что БФ являются объектами, с которыми можно выполнять операции учета, контроля и планирования, измерять и оценивать их эффективность. Бизнес-функция может выступать как экономическая категория (приставка «бизнес» к этому обязывает). С точки зрения методики IDEF0 бизнес-функция — это нижний уровень декомпозиции.

В контексте корпоративных информационных систем БФ приобретает две интерпретации. В первом случае имеется однозначное соответствие между технологическим оборудованием и операциями: по операции восстанавливается аппарат, ее производящий. Здесь БФ понимается как операция, реализуемая на конкретном оборудовании. Описание БФ для этого случая — это описание операции.

Во втором случае на выполнение операции может быть много претендентов. В качестве примера возьмем деревообрабатывающие станки и сверление отверстия: эту операцию в принципе можно выполнить на нескольких типах станков — сверлильном, токарном или фрезерном. Выбор же оптимального исполнителя происходит в результате работы планирующей процедуры. Поэтому вторая и наиболее интересная интерпретация БФ — это роль, т. е. набор требований, предъявляемых к исполнителю. В момент планирования БФ происходит занесение конкретных значений полей (если описание БД реализовано в виде таблицы базы данных) «кандидат» и «время начала», эта процедура называется еще параметризацией БФ. Для того чтобы подобрать кандидатов на выполнение, должно существовать формализованное перечисление их функций (в смысле возможностей). Если речь идет о персонале предприятия, то это список того, чтоў каждый из сотрудников умеет делать, или функциональное досье. Функции, требуемые ролью и имеющиеся в досье, должны быть приведены к «одному уровню». Это означает, что функциональное досье сотрудников и механизмов, с одной стороны, и описания ролей — с другой, находятся в отношении взаимосогласованности и понимаются как своеобразные функциональные предложения и функциональные запросы.

Для получения формализованного представления предприятия нам потребуются специальные понятия. Они описывают и технологические, и административные процессы (до определенного уровня, конечно). Нужная дескриптивная сила описания достигается включением в него различных элементов: бизнес-функций (БФ), бизнес-процессов (БП) и бизнес-систем (БС). Все они подробно рассматриваются во врезках.

Базовые алгоритмы

Итак, мы выбрали понятийный базис для описания работы всего предприятия. Однако, используя только его, можно получить лишь статическую модель. Как заставить БФ и БП выполняться в нужном ритме, подчинить их производственным целям, придать им динамику? Вообще говоря, нам надо решить с помощью введенных понятий три задачи: проанализировать целесообразность выполнения заказа, подготовиться к его выполнению и выполнить его, если он признан целесообразным и прошел фазу подготовки.

Фаза описания заказа и анализа его привлекательности

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

Исходные параметры для анализа заказа

Процедура анализа привлекательности заказа имеет на входе целый ряд параметров. Вот лишь некоторые из них:

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

***

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

Другая аналитическая технология работает на основе статического анализа списка исходных параметров заказа. Как видно из врезки, далеко не все они содержатся непосредственно в тексте договора.

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

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

Таким образом, отобранные с помощью некоей технологии — хотя бы и вручную — заказы суммируются в план выпуска и передаются в ERP-cистему. Этим данная фаза заканчивается.

Фаза подготовки к выполнению заказа

Именно на этой фазе проявляются основные возможности существующих сегодня ERP-систем. Это формирование разноуровневых заданий подразделениям и рабочим центрам предприятия. Получение заданий базируется на алгоритмах разузлования и размаршручивания (Разузлование — алгоритм конструктивной декомпозиции изделий; размаршручивание — детализация технологических операций и планирование производственных мощностей. — Прим. ред.). Главный алгоритм — это нисходящий алгоритм разузлования — определение что, кому и когда делать. Все популярные ныне технологии организации производственного процесса, например Just in Time2, базируются на таких алгоритмах.(Технология планирования производственного процесса, в котором комплектующие и сырье поставляются партнерами непосредственно перед производством окончательного продукта, что позволяет свести к минимуму запасы материалов и потребности в складах.)

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

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

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

  • не более трех заданий в смену,
  • не более 20 ч производственной деятельности в неделю,
  • не более 3 ч за аппаратом номер 8,
  • между заданиями перерыв не менее 2 ч,
  • не более 4 ч непрерывной работы,
  • на операции 45, 29 и 14 кандидата 3 не привлекать.

В результате мы получаем график проведения БФ, необходимых для изготовления конечного изделия или производства нужной услуги.

Бизнес-процессы

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

Рис. 1 Цепочки простейших БФ (БП нижнего уровня формализации)

Рис. 1 Цепочки простейших БФ (БП нижнего уровня формализации)

Как видно из рис. 1 БП — это граф с бизнес-функциями в качестве вершин. С помощью графов задаются алгоритмы выполнения некоей производственной или административной задачи. Но граф является лишь исходным шаблоном, который в дальнейшем доопределяется и становится заданием, поручаемым конкретному исполнителю. Такие шаблоны можно построить практически для самых разных производственных задач. Если шаблон относится к технологической деятельности, то он может совпадать с технологическим маршрутом или маршрутной картой (route), быть операционной реализацией сборочных спецификаций (BOM — Bill Of Materials, по терминологии, принятой в MRP II) или же комбинацией двух последних. У нас в стране до сих пор работает ГОСТ 3.1118-82, в котором определяется, чтоў такое маршрутная карта и как ее задавать. Маршрутную карту вполне можно понимать как БП.

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

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

Рис. 2 Управление производством (БП верхнего уровня формализации)

Рис. 2 Управление производством (БП верхнего уровня формализации)

На наш взгляд, верхней границей применимости понятия БП разумно считать набор задач, представленный на рис. 2.

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

Для завершения картины будем считать, что предприятие в целом — это бизнес-система (БС). Фактически БС является начальным уровнем декомпозиции предприятия. Инструментом декомпозиции может служить методология IDEF0. Функции в верхних блоках диаграмм IDEF0 соответствуют функциям структурных подразделений, функции в нижних блоках — обязанностям отдельных исполнителей. Внутри БС содержатся бизнес-процессы и бизнес-функции (как операторы и подпрограммы в главной программе) и исполнительная среда, или супервизор БП.

***

Но это теоретически. На практике основная проблема состоит в отсутствии тщательно продуманных реальных БП, вернее, в невозможности их существования (в отрыве от конкретного предприятия и от контекста исполнения). Они в виде библиотек шаблонов должны, по идее, появиться на фазе внедрения или даже обследования. Но учесть a priori все действительно требующиеся операции невозможно. Часто приходится выполнять вспомогательные и непредусмотренные операции на ходу, например:

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

Очевидно, что учесть загодя все реально необходимые БФ невозможно. Поэтому в БП для его выполнимости необходимо закладывать отнюдь не минимальные межоперационные задержки. Процедуру параметризации БП выполняют обычно непосредственно перед его выполнением. Если же приходится планировать предварительно, то надо оставлять большие временные «зазоры» для решения возникающих проблем на месте. Поэтому из-за всех коллизий жизни точное планирование просто бессмысленно и используется «приблизительное планирование», что означает включение в БП только абсолютно всегда необходимых БФ.

Задание семантики языка описания производственной активности

Чем хорош язык IDEF0-диаграмм для задания семантики БП? Семантика любого блока IDEF0 задается его декомпозицией. Важно то, что при декомпозиции можно сменить язык интерпретации операций верхнего уровня. Например, процесс «сверление» можно разложить в базисе операций: подать деталь, закрепить ее, вставить сверло, подвести сверло, выполнить сверление — или же в базисе подпрограмм: выполнить подпрограмму сверлить с параметрами диаметр 15, глубина 25, резец № 6. От того, как определить операцию «сверление», зависит, какой язык будет выбран для следующего слоя декомпозиции.

Что значит задать семантику БП? Это означает описать взаимодействия в триаде «БП — монитор выполнения — исполнитель». Здесь, к счастью, все достаточно просто. На монитор не возлагаются функции компиляции или интерпретации БФ для передачи ее исполнителю. По заголовку БФ ему достаточно просто найти соответствующего исполнителя.

Наиболее известные труды по заданию семантики касались в основном языков программирования и были рассчитаны на реализацию этой семантики в ЭВМ. Проблема состояла в том, как с помощью языка программирования передать вычислительной машине намерения программиста. Задать семантику означало показать, как вычислительной машине реализовать тот или иной оператор языка. Примером определения семантики языка программирования может служить Венский метод, разработанный венской группой IBM.

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

***

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

Фаза выполнения заказа

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

Если говорить упрощенно, то на уровне БС нужен монитор заданий, или, если выражаться более точно, среда исполнения заданий. (Функции монитора смотри во врезке.) Благодаря таким возможностям монитора можно выделить те случаи, когда управление можно «поручить» программе; в тех же случаях, когда программа бессильна, она должна «передавать» управление персоналу.

Управляющую логику, полученную на фазе подготовки, нам надо поместить в монитор для ее выполнения. Регламент взаимоотношений монитора как исполнительной среды и загружаемой в него программы (графа БП) должен быть стандартен. Теоретически монитор может выполнять программу, представленную в виде текста, графа или, например, сети Петри. (Для описания логики бизнес-процессов можно использовать синтаксис классического языка графов, сетей Петри, конечных автоматов (Мура или Мили), СМО (систем массового обслуживания) или даже тардиционных языков программирования Cи или Pascal.) Если БП представлен в виде графа, то монитор должен последовательно обходить его вершины, если же в виде текста, то он должен уметь выделять лексемы. Приведенный в настоящей статье монитор ориентирован на то, что его программа — граф. (Большинство разработчиков ERP-систем придерживаются именно такой парадигмы.)

В результате монитор, обходя граф БП, в каждой его вершине будет реализовывать следующий алгоритм:

  • счетчик текущей БФ увеличивается на указанное приращение;
  • выборка БФ, на которые указывает счетчик;
  • передача заданий исполнителям;
  • захват, регистрация и разбор отчетов;
  • переход к следующей вершине БП или оповещение персонала, если не поступили сигналы обратной связи.

Понятно, что граф БП должен быть создан еще на фазе подготовки заданий, где он описывается и верифицируется.

Заметим, что на фазе выполнения БП необходимо учитывать его природу. Так, задания для программируемых механизмов, например станков с ЧПУ, и для персонала формируются и контролируются по-разному. Административный процесс почти всегда имеет меньшую вероятность своего своевременного выполнения в отличие от технологического. (Типичный пример: лапочка-секретарь по дороге заговорилась с подругой, задержав таким образом передачу исполнителю критически важного документа.) Естественно, что и мониторинг объектов различной природы необходимо осуществлять по-разному. От того, как реализован мониторинг, вообще говоря, зависит, имеем ли мы дело с системой планирования или настоящей системой управления. ***

С помощью описанной методики мы можем сначала «разобрать» предприятие, вплоть до функциональных ячеек и отдельных команд управления ими. Далее, мы можем агрегировать функциональные ячейки в более сложные образования, динамически формируемые последовательности для выполнения тех или иных задач. Эти последовательности выстраиваются сообразно выявленной структуре предприятия и в соответствии со спецификациями заказов. На фазе выполнения ERP-система позволяет оперативно управлять сформированными последовательностями, используя определенные команды.

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





  
3 '1998
СОДЕРЖАНИЕ

колонка редактора

• В борьбе GSM и CDMA победила дружба

локальные сети

• Кабельные системы для офисных зданий. Часть I. История, приложения, стандарты

• Быстрые устройства для быстрых сетей

• Когда сервер NetWare работает медленно

• В поисках решения удаленного управления

корпоративные сети

• Коммутаторы ATM на магистрали корпоративной сети

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

• Четыре монитора транзакций для корпоративных приложений

услуги сетей связи

• Системы WLL на российском рынке

• Технологии ХХI века и российские университеты

• Европейская конференция по АТМ

• Передача голоса по сетям ATM (часть II)

• Передача данных по каналам телевещания

• Телевидение: от кабельного к эфирному и далее...

системы учрежденческой связи

• Конкурентоспособны ли отечественные УАТС?

• Такие разные автоинформаторы

интернет и интрасети

• За подрядами - в Интернет!

• Оправдает ли ожидания WinSock 2?

• Электронная коммерция в России

защита данных

• Секреты виртуальных частных сетей

бизнес

• 3Com-OCS: связь напрямую

новые продукты

• 101-й "козырь" фирмы RAD, Allied Telesyn выходит на рынок средств удаленного доступа

только на сервере

• Новые горизонты локальных сетей



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх