World Optimizer Club

    Формальное описание бизнес процессов

Предисловие

Как улучшить систему управления?

  1. Надо действовать локально, не пытаться улучшить все сразу, а локализуя и пересматривая отдельные бизнес-процессы
  2. При этой локализации важно, насколько влияет данный процесс на работу предприятия в целом, но еще важнее насколько люди занятые в даном процессе готовы к его пересмотру.
  3. Надо идти от реальности, так как иначе будут потеряны существенные стороны производственного процесса
  4. Существующую реальность надо оценивать критически, сохраняя содержание, совершенствовать форму, отбрасывая устаревшие звенья, по возможности полно используя возможности современных компьютеров.
  5. Описывая реальность и предлагая алтернативы надо доводить дело до работающих информационных систем, на практике проверяя возможность работы людей по новым сценариям
  6. Новейшие технологии программирования позволяют на этом пути строить и модифицировать бизнес-процессы и поддерживающие их информационные системы в течение нескольких дней. (Традиционные подходы требуют для этого много месяцев).
  7. Ключевым пунктом на этом пути представляется формальное описание бизнес процессов

Как описать существующие процессы управления и процессы предлагаемые?
Каковы должны быть правила и стнадарты такого описания?
Очевидно, что стандартное описание должно

  1. содержать всю необходимую информацию
  2. быть формально проверяемым на правильность
  3. быть принципиально человеко-понятным
  4. допускать преобразование в легко-понятные формы

За основу стандарта был принят язык XML. Покажем как описать на этом языке элементарный бизнес процесс.

Рассмотрим, например, элементарный бизнес процесс "создание электронного почтового ящика для нового пользователя локальной сети предприятия".

Этот процесс должен протекать так: (неформальное описание)

  1. Клиент должен написать служебную записку на имя директора Центра Компьютеризации Лангвагена М.А. В этой записке следует указать следующие обязательные данные
    1. Фаимилию Имя Отчество клиента
    2. служебный телефон клиента
    3. адрес рабочего места клиента (здание, номер комнаты, этаж)
    4. сетевое имя компьютера
    5. почтовое имя клиента
    6. отдел клиента

     

  2. Служебную записку следует заверить у начальника отдела
  3. Служебную записку следует заверить у замдиректора по вопросам безопасности
  4. Служебную записку следует передать директору Центра Компьютеризации
  5. Директор Центра Компьютеризации поручает системному администратору создать почтовый ящик
  6. После того как системный администратор создал почтовый ящик, он звонит об этом клиенту.
  7. Клиент проверяет, что ящик работает. Если ящик не работает, клиент решает эту проблему совместно с системным администратором.

Вот как выглядит описание этого процесса на языке XML

<?xml version="1.0" encoding="UTF-8"?>

<!--
Document : newmailbox.xml
Created on : 4 Август 2003 г., 16:13
Author : jacob feldman
-->

<model>
<scenario version="0">
<create_person role="sysadmin" name="larionov"/>
<create_person role="client" name="vilkova" />
<create_person role="clientboss" name="petrov"/>
<create_person role="securityboss" name="brunetkin" />
<create_person role="ccboss" name="langvagen"/>
<create_document type="order4newmailbox" name="order" master="vilkova">
<docitem name="firstname" value="tatyana"/>
<docitem name="lastname" value="vilkova"/>
<docitem name="department" value="223"/>
<docitem name="laboratory" value="11"/>
<docitem name="building" value="main"/>
<docitem name="level" value="2"/>
<docitem name="apartment" value="115"/>
<docitem name="computername" value="vilkova"/>
<docitem name="mailboxname" value="vilkova"/>
<docitem name="phone" value="1788"/>
</create_document>
<sign_document what="order" who="petrov"/>
<sign_document what="order" who="brunetkin"/>
<send_document from="vilkova" to="langvagen"/>
<send_document from="langvagen" to="larionov"/>
<execute_job master="larionov" document="order" job="createmailbox"/>
<call_phone from="larionov" to="vilkova" about="order" />
<execute_job master="vilkova" job="checkmailbox"/>
</scenario>
</model>

В этом описании есть все необходимые данные. Обратите вимание на то, что в описании указан совершенно конкретный вариант проесса. Например указан не "клиент вообще" а клиент "Татьяна Вилкова" с телефоном 17-88.

Это описание может быть формально проверено на правильность.

Это описание можно прочитать и понять.

По этому описанию можно автоматически построить презентацию (анимацию) "как это происходит".

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

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

  1. Показанное преобразование XML-описания в презентацию было сделано в ручную. Это значит, что при каждой можификации описания придется вручную переписывать презентацию. Необходима программа "Вьюер" которая будет делать это в автоматическом режиме
  2. Хотя XML описание можно создать в любом текстовом редакторе, было удобно иметь "Визуальный редактор" где добавление нового человека или документа можно было бы осуществить обним нажатием кнопки.
  3. Хотя язык XML имеет собсвенный стандарт, необходимо определить какие объекты можно создавать и какие параметры необходимо в них указывать. Такой специальный стандарт следует выработать в процессе реального описания 5-7 реальных бизнес процессов и в дальнейшем его придерживаться.
  4. Создаваемые описания следует хранить в специальной библиотеке ("репозитарий"). Предполагается накопление и повторное использование описаний для сравнения и анализа.

Предположим, что мы решили улучшить определенную независимуя часть процесса. Нам придется

  1. описать формально существующие процессы управления.
  2. предложить альтернативы
  3. выбрать лучший из предлагаемых вариантов

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

Теперь, собственно при создании Информационой Системы, можно использовать новую модель даных (моя оригинальная разработка под условным названием FTS, Я.Ф.) позволяющую строить и модифицировать Информационные Системы за несколько дней (традиционные модели требуют для этого не менее трех месяцев). Так быстрое (дни) описание бизнес-процессов согласуется с быстрым (дни) созданием поддерживающих информационных систем.

Последняя группа проблем которую необходимо здесь решить это проблема тестирования (QA, quality assurance, контроль качества). У этой проблемы три слоя.

  1. Формальная стабильность. Система не должна зависать и не должна выбрасывать непонятные сообщения. Для этого надо построить программу-автомат.
  2. Содержательная правильность. В важных случаях система должна работать так как автор системы мы предполагает. Поскольку все важные частные случаи вошли в набор формальных описаний, надо построить программу-полуавтомат, которая по каждому такому описанию посылала на сервер цепочку команд. Автор системы визуально оценивает реакцию системы на эти команды и сам определяет содержательную правильост работы системы.
  3. Интуитивная прозрачность. Во всех случаях система должна делать примерно, то что человек со стороны может интутивно от нее ждать. Для этого надо посадить за систему реальных пользователей.

Таким образом наличие формальных описаний позволяет решить самую сложную из проблем тестирования - проблему содержательной правильности.

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

Фельдман Я. А. 8 августа 2003

К остальным статьям

© 2003 Elena and Jacob Feldman