Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Процессный паттерн: “Внутренний заказ”

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

В BPMN каждый процесс моделируется отдельным пулом (pool). Например, вот как может выглядеть цепочка “клиентский заказ” - “заказ на производство” - “заказ на приобретение комплектующих”:

Диаграмма BPMN

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

Такое асинхронное взаимодействие процессов подразумевает наличие между ними буферов, в которых накапливаются задания, передаваемые от процесса-заказчика к процессу-исполнителю. В рассматриваемом примере это “Производственные заказы” и “Плановые остатки сырья и комплектующих”. Технически буфер может реализовываться по-разному: очередью сообщений, записями таблицы базы данных или объектами ERP-системы, находящимися в определенном состоянии. Естественно, внутреннее устройство буфера желательно скрыть, создав сервисы для работы с ним - добавления, просмотра, извлечения.

Современные BPMS позволяют и моделировать, и исполнять подобные схемы, и в этом их коренное преимущество перед традиционными workflow-системами. Другое дело, что аналитики осваивают такие схемы с большим трудом - см. например Bruce Silver, “BPMN to Requester: Get Outta My Pool”. Основная сложность тут не в нотации, а в развитии “асинхронного мышления”. Вы должны научиться вычленять из того, что бизнес преподносит вам как единый процесс, отдельные асинхронные процессы. Помогают разобраться в этом ответы на два вопроса: 1) с каким бизнес-объектом связан экземпляр процесса и 2) с какими событиями связаны начало и завершение экземпляра процесса.

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

Интересно, что прием на работу - это классический пример бизнес-процесса, который BPM-вендоры любят использовать для демонстрации своих продуктов. Но при этом они пытаются обойтись одним процессом! Видимо, такие демонстрации делают разработчики, а не консалтеры.

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

14.01.09 | Статьи | , ,    

Комментарии (36)

  1. Юрий Зеленков 21.01.09 14:48

    Готов подписаться под каждым словом. Признаюсь, сам долго не понимал, к чему все эти асинхронные взаимодействия в BPMN, но жизнь научила.

    Однако, хотелось бы двинуться дальше. Действительно возникают всякие буферы между процессами, которые должны хранить различные объекты. А процессы должны уметь писать-читать эти объекты. Но если делать соответствующие сервисы на Java или .Net - это история долгая и мучительная. Заявляю это на основании личного опыта - занимаеся этим 1,5 года вокруг TeamCenter. В то же время есть правильные высокоуровневые языки (Ruby, Python, Groovy,…), которые превращают все махинации с объектами в удовольствие. Только нет BPMS, написанных на Ruby, Python, Groovy… Вам такие не известны?

    И некоторые сомнения по поводу терминологии.

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

    Получается, что один процесс - это хореография. Много взаимодействующих асинхронных (оркестр!) - оркестровка.

    А теорема без доказательства - это лемма.

  2. Anatoly Belychook 21.01.09 14:59

    По Ruby посморите заметку Николая Войнова http://nvoynov.blogspot.com/2008/11/openwferu-open-source-ruby-workflow-and.html Сам собираюсь, пока руки не дошли.

    Я думаю, тут вот какая аналогия: в оркестре всем управляет дирижер. Танец - это искусство вести партнера и подстраиваться под него. (Подразумевается, что танец в одиночку - это не танец.)

    В продолжение этой заметки собираюсь поделиться своими соображениями о параллелях между синхронными-асинхронными делами и теорией ограничения Голдрата - оставайтесь на связи!

  3. Сергей Смирнов 23.01.09 19:17

    По поводу терминологии: термины хореография и оркестровка вполне корректны, на мой взгляд. По крайней мере, в английском языке их аналоги choreography and orchestration применяются именно в таких значениях в области BPM.

    BPMN дает большую свободу при моделировании. Поэтому нельзя сказать, что есть “правильные” или “неправильные” модели. Я хочу дать некоторые комментарии по поводу модели BPMN:
    1. Все действия в диаграмме названы существительными. По моему мнению, с методической точки зрения, значительно лучше именовать действия глаголами. Например, “Аванс”-”Получить аванс”, “Запуск в производство”-”Запустить в производство”, “Отгрузка”-”Отгрузить товары”.
    2. Идея с асинхронными бизнес процессами корректна, но в терминах пулов BPMN она выражена не совсем правильно. Пулы предназначены для отображения участников бизнес процесса. Таким образом, пул “Приобретение комплектующих” может быть переименован в “Отдел закупок”. Пул “Производство” имеет корректное имя, если рассматривать его не как название бизнес процесса, а название подразделения. Пул “От заказа до оплаты” можно разделить на несколько пулов. Например, на бухгалтерию, которая получает аванс и занимается оплатой и расчетами, и отдел логистики, который отгружает товары.
    3. Сообщение, которое посылается по окончанию производства (в пуле “Производство”) может обрабатываться отдельным событием (intermediate catching message event), которое нужно добавить после действия “Запуск в производство”. Это позволит визуально показать, что процесс ожидает получения этого сообщения.
    4. Циклическое действие в пуле “Производство” может быть также заменено действием “Множественные экземпляры” (multiple instance activity). Это отразит, что действие выполняется для каждого объекта из множества.

  4. Иной 24.01.09 05:26

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

  5. Anatoly Belychook 25.01.09 13:16

    Комментарии к комментарию Сергея:
    1) Согласен, это стандартная рекомендация. Просто не хотелось загромождать диаграмму длинными названиями, это ведь всего лишь эскиз.
    2) Вы ошибаетесь. Представление о том, что пулы - это участники процесса, является заблуждением. Впрочем весьма распространенным. Собственно, способствовать искоренению этого заблуждения было одной из целей данной заметки.
    См. заметку Брюса Силвера на эту тему http://www.brsilver.com/wordpress/2008/06/11/bpmn-to-requester-get-outta-my-pool/
    “One of BPMN’s most important elements is unfortunately also the most misunderstood. It’s called a pool, a rectangular shape that serves as a container for a process. So in that sense a pool is synonymous with a process, and that’s as basic as you can get… One of the confusing things to business analysts who find the time to read the BPMN spec is that the spec says pools are used to distinguish process “participants.” But the spec means participants in the SOA sense, i.e. requester or provider, not in the sense of roles within the orchestration, like Manager and HR. Those are depicted as lanes within the internal process pool.”
    “Приобретение комплектующих” не следует переименовывать в “Отдел закупок”. Отдел закупок - это swimlane внутри этого процесса, наряду с прочими.
    3) Считайте, что получатель сообщения находится внутри подпроцесса “Запуск в производство”.
    4) Согласен, multiple instance на этой диаграмме были бы более уместны, спасибо за подсказку.

  6. Anatoly Belychook 25.01.09 13:23

    Иной, вы правы, идея “поиска одного, правильного алгоритма” ошибочна, как раз об этом я писал в заметке http://mainthing.ru/ru/item/131/. Здесь же речь идет о том, что необходимой гибкости можно достичь, разбив сквозной процесс на отдельные процессные компоненты. Эти компоненты как раз и будут инициироваться “разными источниками и с разной скоростью”.

  7. Сергей Смирнов 28.01.09 15:42

    О пулах

    я решил углубиться в документацию и обратился к спецификации BPMN (BPMN 1.2, впрочем это верно и для версий 1.0 и 1.1). В разделе 9.6.2 я нашел, что:

    “A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g., a company) or can be
    a more general business role (e.g., a buyer, seller, or manufacturer).”
    то есть
    “Пул представляет участника в процессе. Участником может быть как конкретная бизнес единица (например, компания), так и бизнес роль в более абстрактном смысле (например, продавец, покупатель или производитель).”

    далее переходим на определение понятия Participant в той же спецификации (Annex C: Glossary):
    “A Participant is a business entity (e.g., a company, company division, or a customer) or a business role (e.g., a buyer or a seller), which controls or is responsible for a business process. If Pools are used, then a Participant would be associated with one Pool.”
    то есть
    “Участник - это бизнес сущность (например, компания, подразделение или клиент) или бизнес роль (например, покупатель или продавец), которая контролирует или ответственна за бизнес процесс. При использовании пулов участник ассоциируется с одним пулом.”

    Мне кажется, что спецификация достаточно однозначно определяет понятие участника, а следовательно мое заблуждение не лишено оснований :)

  8. Anatoly Belychook 28.01.09 20:33

    Сергей

    ОК, давайте заглянем в спецификацию BPMN 1.1, http://www.bpmn.org/Documents/BPMN%201-1%20Specification.pdf (Кстати, на bpmn.org есть только версии 1.0, 1.1 и RFP к версии 2.0.)

    Раздел 7.1, “BPMN Scope”, подраздел “Abstract (Public) Processes” (стр.13):

    “This represents the interactions between a private business process and another process or participant… Abstract processes are contained within a Pool and can be modeled separately or within a larger BPMN Diagram to show
    the Message Flow between the abstract process activities and other entities.”

    Чуть ниже, подраздел “Types of BPD Diagrams” (стр. 14):

    “Within and between these three BPMN sub-models, many types of Diagrams can be created. The following are the types
    of business processes that can be modeled with BPMN:
    o Detailed private business process with interactions to one or more external entities (or ‘Black Box’ processes)
    o Two or more detailed private business processes interacting
    o Detailed private business process relationship to Abstract Process
    o Detailed private business process relationship to Collaboration Process
    o Two or more Abstract Processes
    o Abstract Process relationship to Collaboration Process
    …”

    Теперь вернемся к упомянутому Вами разделу 9.6, но только к самому его началу (стр. 86):

    “BPMN uses the concept known as ’swimlanes’ to help partition and/organize activities. It is possible that a BPMN
    Diagram may depict more than one private process, as well as the processes that show the collaboration between private
    processes or Participants. If so, then each private business process will be considered as being performed by different
    Participants. Graphically, each Participant will be partitioned; that is, will be contained within a rectangular box called a
    ‘Pool.’ Pools can have sub-Swimlanes that are called, simply, ‘Lanes.’

    Section 7.1.1, ‘Uses of BPMN,’ on page 12 describes the uses of BPMN for modeling private processes and the
    interactions of processes in B2B scenarios. Pools and Lanes are designed to support these uses of BPMN.”

    Получается, дважды прав Брюс Силвер: во-первых, за пулом может стоять процесс. А во-вторых, действительно, некоторые аналитики испытывают трудности с пониманием концепции пула :)

    Если серьезно, то спецификации BPMN всех версий не критиковал за противоречивость только ленивый, на них прямо-таки горит клеймо “design by committee”. По-видимому, можно трактовать и так, и эдак. Но я человек практики, и я на практике убедился, что трактовка пула как процесса позволяет создавать более ясные и логичные диаграммы. Поэтому за эту трактовку и агитирую.

  9. Сергей Смирнов 28.01.09 21:40
  10. Anatoly Belychook 28.01.09 21:54

    ОК, спасибо. Совсем свежий документ, видимо поэтому на bpmn.org и нету ссылки.

  11. Артем 06.02.09 16:51

    А допускает ли нотация детализировать swimlines, если, например, мне необходимо отразить разные службы внутри одного отдела. Заранее благодарю за ответ.

  12. Anatoly Belychook 06.02.09 17:41

    swimlAnes. Нет. Это как дорожки в бассейне - никакой иерархии или группировки.

  13. Сергей Смирнов 06.02.09 18:19

    Уважаемые Артём и Анатолий,

    BPMN 1.0, 1.1 и 1.2 допускают размещать внутри одной дорожки другую дорожку. Версии спецификации 1.1 и 1.2 даже приводят примеры таких диаграмм (см. рисунок 9.38 на странице 91 по адресу http://www.bpmn.org/Documents/BPMN%201-1%20Specification.pdf) Более того, спецификация как раз приводит в пример подотделы и службы внутри него в качестве примеров, когда допускается такой прием моделирования.

  14. Anatoly Belychook 06.02.09 20:23

    Сергей

    Спасибо. Хорошо что у нас есть человек, профессионально изучивший стандарты. Я знал - Вы меня поправите если навру :)

  15. Артем 10.02.09 18:47

    Коллеги, спасибо за ответ. И еще вопрос. Возможно ли, чтобы подпроцесс имел на выходе более одного потока. Например, я отразил действие в результате которого может быть ветвление процесса - тут все ОК, нотация допускает. А потом я решил детализировать данное действие и преобразовал его в подпроцесс. Как это будет выглядеть? Один поток, а затем условие с ветвлением; два потока; варианты…

  16. Anatoly Belychook 12.02.09 13:54

    Подпроцесс может иметь больше одного выхода как в варианте exclusive, так и в варианте parallel gateway. Но при возврате в вызывающий процесс они сольются в один поток. Например, предположим, что в подпроцессе стоит gateway с проверкой “сегодня выходной?” с двумя выходящими из него переходами к шагам “работа”, “отдых”, за каждым из которых следует end event. При возврате в вызывающий процесс эти два потоком сольются, и если это не то, на что вы рассчитывали, то вам придется в вызывающем процессе поставить еще один gateway фактически с такой же точно проверкой.

    Это конечно не слишком удобно. Для сравнения, в Unify NXJ сделано нестандартно, но удобнее: вы можете пометить два выхода в подпроцессе соответственно как “работа” и “отдых”, а в вызывающем процессе изобразить две стрелки, выходящие из подпросса, пометив их точно так же. Результат будет ожидаемый: в зависимости от результатов подпроцесса вызывающий процесс продолжить работу по одной или другой траектории.

    Возвращаясь к BPMN, преодолеть это неудобство при помощи message flow не получится, но можно воспользоваться механизмом exception. Например, в нашем примере можно принять решение, что “отдых” - это исключение. Соответственно, внутри подпроцесса на определенном шаге оно будет генериться, а на выходе - перехватываться при помощи attached intermediary event.

  17. Anatoly Belychook 12.02.09 13:56

    Более подходящее место для обсуждения тонкостей BPMN - http://www.uml2.ru/forum/index.php?board=9.0

  18. Артем 12.02.09 14:14

    Спасибо за исчерпывающий ответ и полезную ссылку.

  19. Олег Ладыженский 09.04.09 15:58

    «Заблуждением» по поводу того, что пулы это обязательно участники процесса послужило скорее всего то, что при словесном описании процесса как-то принято выделять участников и исполняемые ими действия. А группировка действий в отдельные подпроцессы это уже скорее абстракция. Даже в вашем примере можно например «рассчёт комплектующих» производить с таким же успехом в пуле «от заката до оплаты». На последовательность действий, асинхронность и скорость исполнения процесса это никак не повлияет, а вот кто, или что будет производить этот рассчёт будет неизменным куда это действие ни поставь.

  20. Anatoly Belychook 09.04.09 16:19

    Олег, боюсь Вас сбил с толку Инталио. Он использует для обозначения исполнителей пулы, хотя вообще-то для этого предназначены свимлэйны, см. http://mainthing.ru/ru/item/154/

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

    “От заката до оплаты” мне понравилось, годится для названия криминального триллера. Оговорка по Фрейду? :)

  21. Олег Ладыженский 14.04.09 11:46

    Не хочу вступать в религиозные воины и защищать Intalio, пусть за меня это сделает этот список продуктов, официально поддерживающих BPMN: http://bpmn.org/BPMN_Supporters.htm

  22. Anatoly Belychook 14.04.09 12:12

    Олег

    Не уловил связи - эти организации поддерживают BPMN, Intalio или Вашу позицию?

    Еще раз: пул = участник процесса. Но участник процесса != пользовательская роль. Это может быть также сторонняя организация или другой процесс.

    Так как BPMN есть продукт коллективного творчества, он оставляет возможность разнообразных трактовок. Приведу два:
    1. Брюс Силвер на своем тренинге по BPMN предлагает роли исполнителей моделировать лэйнами, а внешние организации и взаимодействующие процессы - пулами.
    2. Intalio лэйнами не пользуется, а моделирует и то, и другое пулами. Формально это правильно, но по существу, на мой взгляд, издевательство.

    Я знаком с несколькими другими продуктами из этого списка, и все они следуют первой трактовке.

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

  23. Рахимжан 28.04.09 09:06

    Коллеги. Если разрешите комментарий от ровесника 1 ЭВМ СССР (МЭСМ - 1950 г презен-товали в 1951г).
    Формулировка действия в виде глагола в повелительном наклонении с указанием объекта-существительного берет свое начало от HIPO (Иерархия, Ввод, Обработка, Вывод ) технологии, предложенной IBM (мы ее тогда называли ИБМ - “как пишется - так и читается”). Потом этот под-ход продолжил свою жизнь в структурном программировании.
    Логика была следующая:
    1. Память ЭВМ превысила 8К ячеек и пришло время писать “БОЛЬШИЕ” программы.
    2. Был предложен метод декомпозиции.
    3. На верхнем уровне абстракции программа ассоциировалась с кнопкой, которая выполняет действие будующей программы. И кнопку следовало подписать, чтобы было понятно, что она де-лает. Например: “Рассчитать месячную программу потребности в контейнерах”. Нажал на кнопку и получил результат. Но такой команды у ЭВМ нет - значит действие следует детализировать.
    4. Дойдя до определенного уровня, полученные результаты можно согласовать с руководи-телем и заказчиком.
    5. Продолжив этот процесс приходим к цельной и быстро отлаживаемой программе.

    Такова была логика.

  24. Рахимжан 28.04.09 09:25

    Анатолий.

    Я солидарен с трактовкой: Процесс = пул, Дорожка = роль участника.

    Попутно хочу задать вопрос.
    А что говорят стандарты по поводу того, что на схеме верхнего уровня мне нужны только пулы, а на схеме второго уровня дорожки внутри пулов?
    Я не хочу комментариев по поводу прав я или не прав.
    Мне бы хотелось получить ответ на свой вопрос.
    Я скопировал все ссылки, которые были в этом очень понравившемся мне обсуждении и докопаюсь до истины.
    Но хотелось бы узнать пораньше.

    Да идеи HIPO это середина 70х

  25. Anatoly Belychook 28.04.09 12:40

    Рахимджан

    В этом мире вообще все связано со всем, см.например http://ammosov.livejournal.com/423796.html

    В BPM есть IPO - и по моему опыту, взгляд на процессы не просто как на последовательность шагов, а на преобразование ресурсов весьма продуктивен - но буква “H” в нем лишняя. Взгляд на процессы как на иерархию категорически противопоказан, так как весь смысл процессного подхода к управлению заключается в решении проблем, возникающих на стыках между подразделениями, а при таком подходе мы приходим к таким замечательным вещам, как “бизнес-процесс бухгалтерии”.

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

  26. Кузин Сергей 16.10.09 09:22

    Анатолий, вопрос наличия иерархии при структурном подходе к моделированию бизнес-процессов вполне логичен. Но из него никак не вытекает “бизнес-процесс бухгалтерии”, ибо бухгалтерия не оперирует бизнес-объектами и вообще не является элементом бизнес-системы.

  27. Anatoly Belychook 16.10.09 10:43

    Сергей

    К сожалению, не могу с Вами согласиться ни по одному из пунктов.
    1) По моему опыту, адекватное моделирование бизнес-процессов приводит ни к иерархии, а к сети процессов. И это существенное, на мой взгляд, различие.
    2) Термин “бизнес-процессы бухгалтерии” неправилен по существу, но к сожалению регулярно используется и аналитиками, и архитекторами. Я утверждаю, что во многих случаях это является следствием иерархической декомпозиции.
    3) Бухгалтерия оперирует, например, контрагентами и сделками. Если это не бизнес-объекты, то тогда я вообще не знаю что такое бизнес-объект.
    4) А что же такое тогда бухгалтерия - элемент фитодизайна офиса? Ну то есть это тоже, конечно :) но ведь не только.

  28. Кузин Сергей 19.10.09 12:08

    Анатолий, буду не только возражать, но и уточнять:
    1. Всё больше убеждаюсь в том, что точка зрения зависит от занимаемого места :-D При взгляде сверху - иерархия, снизу - сеть. Разные точки зрения приводят к разным картинам. Кстати, как Вы определяете “сеть процессов”?
    2. Некорректное использование терминологии говорит только о непонимании перечисленными ролями предмета разговора. Но вот причинно-следственную связь не улавливаю, прошу меня извинить.
    3-4. От того, что в бухгалтерии используют бизнес-понятия, не следует, imho, что её процессы относятся к бизнес-процессам. Задам тогда такой вопрос: сможет ли бизнес (бизнес-система) существовать без бухгалтерии как подразделения, в котором выполняются регламентированные государством надзорные функции, если эти требования вдруг будут сняты?

  29. Anatoly Belychook 19.10.09 13:13

    1. У иерархии есть вершина и есть остальные узлы, у каждого из которых строго один родитель. Для сети ни первое, ни второе утверждение неверны. С точки зрения практической полезна аналогия: программирование “сверху-вниз” (иерархия программных модулей) и объектное программирование (сеть объектов). Я ратую за то, чтобы при проектировании процессов, как и при проектировании кода, создавать сетевые, а не иерархические структуры.
    3-4. В соответствии с методологией Lean, есть процессы которые создают ценности, есть процессы, которые ценности не создают, но являются необходимыми, и есть такие, которые не создают ценность и не являются необходимыми (и поэтому подлежат устранению). Вы намекаете на то, что вторые процессами не являются? Кроме того, бухгалтерия занимается не только отчетностью для надзорных органов: скажем, расчетный отдел часто структурно относится к бухгалтерии, а ее материальный отдел занимается управленческим учетом, т.е. задачами в рамках вспомогательных бизнес-процессов. Поэтому постановка Вашего вопроса, на мой взгляд, неверна - бухгалтерия не является таким подразделением.

  30. Кузин Сергей 19.10.09 13:48

    1. Нужно попробовать.
    3-4. БСЭ: “Бухгалтерия (от нем. Buchhalter — бухгалтер, от Buch — книга и halten — держать), 1) ведение бухгалтерского учёта. 2) Самостоятельное структурное подразделение предприятий и организаций, осуществляющее бухгалтерский учёт, составление отчётности и контроль за соблюдением финансовой и сметной дисциплины.”
    Основное предназначение - удовлетворение фискальный требований государства. То, что дополнительно навешиваются на тех же людей или передаются в то же подразделение другие функции (управленческий учёт, …) не говорит об отношении процессов бухгалтерии в чистом виде в манипуляциям с бизнес-объектами. Разумеется, в отношении российской двойной действительности :-)
    Мнение Ваше понятно, спасибо за точку зрения :-)

  31. Julia Wagner 19.10.09 16:05

    Сергей, Анатолий,
    позвольте высказать некоторые соображения по поводу “бизнес-процессов бухгалтерии”.
    “3) Бухгалтерия оперирует, например, контрагентами и сделками. Если это не бизнес-объекты, то тогда я вообще не знаю что такое бизнес-объект.” я бы так не сказала…
    Бухгалтерия не оперирует ни контрагентами, ни сделками, поскольку оперировать - означает оказывать влияние, менять состояние объекта. Бухгалтерия лишь констатирует состояние объекта в числовом выражении. То есть, бухгалтерия обрабатывает данные. Но вот тут уточнение: она может не только обрабатывать данные, но и оперировать ими. К примеру, при наличии кредиторской задолженности, бухгалтерия может блокировать подписание договора с контрагентом (ну, или, по крайней мере, оказать определенное влияние). А это уже имеет отношение к бизнесу, не так ли?

  32. Anatoly Belychook 19.10.09 16:39

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

  33. Julia Wagner 19.10.09 17:55

    Да нет, конечно, но ты меня заставил вот о чем задуматься: представь, что на предприятии есть корпоративная система. Выпиской счетов занимаются менеджеры, накладными - тоже. Короче, все сделки регистрируются в системе без участия бухгалтерии. В БД капают данные. Бухгалтерия их группирует, обрабатывает, составляет отчеты - но это в стороне. Реально в ходе процесса она не задействована. Некоторые ее функции (например, сообщить размер задолженности) выполняет БД (к ней обратились - она “сказала”). Участвует ли в этом случае бухгалтерия в бизнес-процессах? Что-то меня терзают смутные сомнения… :) Сразу говорю: сомнения свежевыявленные. Может уже “перемногодумала”?

  34. Кузин Сергей 20.10.09 09:02

    Юлия, нет, конечно, не “перемногодумали” - в ряде компаний именно так и обстоят дела, а сама “бухгалтерия” вообще находится на аутсорсинге - получает периодически первичку, готовит и сдаёт отчётность. Да ещё можно заметить, что зачастую бухгалтерия использует лишь определённую часть финансовых данных по контрагентам. И ничего, не парится по этому поводу :-) Чего бизнес себе уже не может позволить.

  35. Julia Wagner 20.10.09 12:55

    Но откуда ж тогда взялись “бизнес-процессы бухгалтерии”? Это не фантазии Анатолия, поскольку я сама была свидетелем многократного использования этого термина. Причем, не только устного, но и в статьях аналитиков. Что это? Либо подмена понятий - документооборот и бизнес-процесс, либо это аутсорсинговая компания, оказывающая бухгалтерские услуги? Ну вот точно не второе.
    А появляется этот термин тогда, когда декомпозиция процессов привязана к организационной структуре предприятия. Как аналитик по этой структуре сползает, такие процессы у него и рождаются. Издержки “иерархического мышления”:)

  36. Кузин Сергей 20.10.09 14:17

    Знаком с “аналитиками структурного процессного подхода” (SADT и IDEF0) - как раз они и просветили. :-) Незнание определения “бизнес-процесс” ведёт к неверному использованию. У этих ребят декомпозиция процессов не вяжется с организационной структурой предприятия - они вообще используют “нормативную 8-ми процессную” (9, 11, 13-ти процессную) модель и локализуют её под конкретное предприятие. И далее уже выстраивается структура ПРОЦЕССНОГО управления.
    Про значение структуры управления (оргструктуры?) очень понравилась характеристика С.Бира из “Мозга фирмы”, Глава 6 “Анатомия управления”: “Формальный плакат структуры компании в кабинете директора представляет нечто такое, к чему мы стремимся, нечто, насколько нам известно, подлежащее пересмотру или то, что надо бы привести в соответствие с сегодняшним днем как изменившееся в процессе эволюции.. Что касается описания обязанностей, то там, где они есть, они сводятся к описанию людей, а не их работы. Дело в том, что работа сама не делается, а её делают люди. В результате люди описывают то, что делает данный человек, или то, что, как думает начальник, делает этот человек, а совсем не такую неодушевленную вещь, как работа. Если бы всерьез попытаться составить описание данной работы, то на спор можно было бы утверждать, что для ее выполнения человека не найти. Тогда данная работа изменяется. Реальные структурные схемы фирм сильно зависят от того, кто именно занимает ведущие посты, и когда такой человек уходит, часто приходится менять структуру.”
    Если С.Бир прав, то нечему удивляться, да ещё при соответствующем уровне Вами описанного “аналитика”. И иерархия, как мне представляется, здесь ни при чём. :-)

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии