Тимур Василенко (timur0) wrote,
Тимур Василенко
timur0

Category:

Бизнес-процессы с большой долей неопределенности: практический пример

В предыдущих статьях этого цикла (I, II) мы рассмотрели модель управления бизнес-процессами, характеризующимися большой долей неопределенности. Рассмотрение вопроса в этих статьях носило в основном теоретический характер - в этой статье мы рассмотрим практическую задачу управления реальным бизнес-процессом "ремонта и доработки модельной оснастки". Этот бизнес-процесс достаточно прост, так что не надо быть специалистом в металлургии, чтобы его понять; вместе с тем это реальный бизнес-процесс, так что за почти полтора года накопилось достаточная статистика, в том числе отклонений, чтобы рассмотрение было интересным. Инструмент автоматизации - Notal System.

Краткое введение в тему: что такое модельная оснастка (для понимания бизнес-процесса не так важно, но все же). В металлургии есть технология литья "в землю" - в песчано-глинистые формы. В детстве в куличики играли? Когда в формочку набираешь влажный песок, переворачиваешь и получается "пирожок", куличик. В стальном литье примерно так же, но там на шаг больше:
1. набираешь песок до краев в опоку (типа кастрюли, но от полуметра до нескольких метров в диаметре)
2. делаешь там углубление нужной формы - какая должна быть отливка
3. собираешь две таких опоки вместе (верх и низ) и в полученную полость заливаешь жидкий металл
Разумеется, там не совсем песок - формовочная смесь, песок с жидким стеклом или эпоксидной смолой; поэтому-то форма и держит форму. Когда металл остынет, песчаная форма разбивается и отливка поступает на дальнейшую обработку (очистку, термообработку и т.д.).
Самое интересное - как же получить выемку нужной формы? А очень просто: делается деревянная модель по форме отливки (ее половины), и она-то и придает нужную форму выемке. То есть почти как "печь куличики", только наоборот, вдавленные в песок. Эта деревянная модель и называется модельной оснасткой.

Что для нас важно:
1. Для каждой детали нужна своя модельная оснастка, то есть её много
2. Модельная оснастка используется многократно - сколько нам надо отливок, столько и наштампуем этой оснасткой, то есть она должна жить долго

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

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

Теперь рассмотрим диаграмму состояний этого бизнес-процесса.


Итак, новая задача может иметь два возможных источника:
1. Она может быть инициирована технологами отдела главного металлурга (ОГМет) - обычно это доработка оснастки;
2. Или она может быть инициирована сталелитейным цехом (СЛЦ) - как правило, это ремонт оснастки.
Содержание работ описывается в дефектной ведомости (она может быть составлена заранее, несколько месяцев назад, но в работу не передавалась, пока не было заказа на эту отливку). Сама же команда на выполнение работ оформляется служебной запиской, которую должен завизировать главный металлург - получение этой визы обеспечивает группа подготовки производства, которая обычно и создает служебные записки ОГМет.
Подписанная служебка (и задача соответственно) поступают на исполнение в модельный цех (МастерФорм, МФ) - параллельно с этим сталелитейный цех должен доставить туда модельную оснастку.
Движение задачи внутри модельного цеха не детализируется. По окончании работ модельная оснастка возвращается в сталелитейный цех, а задача передается в группу подготовки производства на контроль исполнения.
Дальше возможны варианты:
- Если работы не вызвали геометрических изменений модельной оснастки (ремонт и некоторые виды доработки), то задача закрывается;
- Если геометрия модельной оснастки изменилась, то надо проконтролировать размеры отлитой по этой оснастке отливки. Поскольку отливать могут не сразу иногда спустя несколько месяцев, то данную оснастку (и данные отливки) надо поставить на контроль, осуществляемый уже за рамками этого бизнес-процесса. Эта функция у нас автоматизирована в 1С и выполняет это ОТК - задача передается им. И вот только после того, как они поставят на контроль, они закрывают задачу.

Вот так выглядит основная траектория этого бизнес-процесса. Заметим, что данный бизнес-процесс обладает интересными особенностями:
1. Отсутствие накопителя - задача сразу имеет исполнителя и никогда не ждет. Это объясняется в основном тем, что функция накопителя (оформленные, но не переданные в работу дефектные ведомости) выведена за пределы этого бизнес-процесса и реализована тоже в 1С, хотя сами документы дефектные ведомости хранятся в Notal System;
2. Два практически равноправных источника задач - ОГМет и СЛЦ.
3. Также два варианта завершения задач - с постановкой на контроль в 1С или без него.

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



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

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



В целом задача данного бизнес-процесса выглядит так:



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

Вот так и организована автоматизация этого бизнес-процесса. За полтора года функционирования этого бизнес-процесса в так автоматизированном виде накопились некоторые выводы:

1. Внедрение этой системы заняло примерно месяц (без ветки СЛЦ, только ОГМет). Диаграмма состояний и маршрут задачи достаточно просты для понимания, так что у технических людей проблем не возникает - эта нотация понятна даже коммерсантам :-)

2. За почти полтора года диаграмма состояний бизнес-процесса несколько раз менялась, причем примерно в половине случаев предложения об изменениях истекали от непосредственных исполнителей - "а нельзя ли добавить вот такой переход?" или "может, это состояние разделить на два?". Наглядность нотации очень способствует включению непосредственных исполнителей в процесс совершенствования бизнес-процесса.

3. На этой диаграмме присутствует "проблемное" состояние (оно желательно на любой диаграмме). За время работы этой системы выявилось, что 90% всех возникающих проблем формулируется так: "задачу передали в работу, а сталелитейный цех уже две недели не везет нам оснастку". Нельзя сказать, что эта проблема была ранее неизвестна, - просто тот факт, что задачи никуда не деваются с диаграммы выявил все такие проблемные задачи и не позволяет им затеряться. Решений этих проблем возможны два:
- цех-таки вывозит оснастку на ремонт/доработку;
- начальником группы подготовки производства совместно с главным металлургом и начальником производства принимается решение отменить эту задачу. Такое решение оформляется еще одной служебной запиской в адрес модельного цеха и задача закрывается как "снята с исполнения".

Надеюсь, из этой статьи стало понятно, как на практике осуществляется управление такого рода бизнес-процессами. В следующих статьях мы рассмотрим управление бизнес-процессами смешанного типа.
Tags: notal system, Профессия
Subscribe

  • Борис Поплавский, коллега Пьера Менара

    Дмитрий Токарев в своей книге " «Между Индией и Гегелем»: Творчество Бориса Поплавского в компаративной перспективе" в главе о дневниках пишет так:…

  • Еще об "Бурю" и образ Калибана в ней

    Когда писал прошлую запись еще в голове не сложилось, почему именно Калибан воспринимается как трагический персонаж? (или драматический - вроде все…

  • Луи Арагон "Гибель всерьез"

    Книга пятьсот пятьдесят третья Луи Арагон "Гибель всерьез" (Louis Aragon "La mise a mort", 1965) М: Вагриус, 1998 г., 400 стр.…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 2 comments