Готовлю сообщение в Телеграм ))

Добрый вечер, продолжаю рассказ о проекте автоматизации Школы бизнеса МИРБИС.
Сегодня расскажу об оптимизации бизнес-процессов.

Экстра важная задача проекта цифровой трансформации – формализовать и оптимизировать бизнес-процессы.
Проектирование бизнес-процессов – важный предшественник автоматизации, дорожная карта автоматизации.
К сожалению, редко удаётся найти тех, кто может работать с бизнес-процессами квалифицировано.
Знаю один крупный телекоммуникационный холдинг, в котором целый отдел занимается «рисованием» процессов.
Знаю девелоперский холдинг, в котором есть департамент для оформления текстово-графического описания бизнес-процессов.
Но ценность описаний процессов в обоих холдингах не высока. Во-первых, потому что менеджеры – владельцы процессов не принимали достаточное участие в описании. Во-вторых, потому что актуальность описаний процессов не поддерживалась.

Я чаще всего придерживаюсь графических методов формализации бизнес-процессов.
В МИРБИС мы проектировали процессы на регулярных еженедельных совещаниях с менеджерами соответствующих процессов.

Приведу пример одного из процессов:

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

Причем приведенная диаграмма процесса это не просто картинка. При двойном клике на процесс открывается словесное описание процесса, при клике на прямоугольник документа, открывается форма документа.

Вот пример еще одного процесса в МИРБИС:

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

Приведенные описания процессов смоделированы в специальном программном продукте Diagram Editor (DE), не продающемся на рынке.
Эта программа отличается от VISIO, самого массового средства описания процессов. В программе DE вы не можете рисовать так называемые дорожки, в которых в VISIO назначаются ответственные за процесс. Соответственно, в VISIO вы сможете наглядно увидеть, кто за какой процесс отвечает. Но в этом есть определённый минус. У вас может получится такое большое нагромождение процессов, когда под каждого ответственного вы будете вынуждены рисовать отдельную дорожку.
Есть средство описания бизнес-процессов ELMA. Оно позволяет крайне детально описать процессы и на основании описания настроить документооборот. Это даже альтернатива в какой-то мере системы «1С: Документооборот».
Есть система Business Studio, которая кроме описания процессов позволяет разработать систему сбалансированных показателей, спроектировать организационную структуру, и много чего еще.
Существует множество других систем описания процессов, каждая из которых имеет свои достоинства и недостатки.

Конечно, мы описывали и оптимизировали бизнес-процессы в парадигме регулярного менеджмента: каждую среду в 16 часов мы собирались (дистанционно или очно) и обсуждали процессы Института. До 10 участников могли собраться на такое совещание – все, кто участвует в описываемом процессе. И совместным, командным творчеством мы формировали описания.
Работа по описанию бизнес-процессов своими силами у нас шла довольно медленно: на один процесс (если его качественно и дотошно описывать) уходило месяца три-четыре, если уделять этому регулярно час-два в неделю. Поэтому мы активно искали специалистов, подрядчиков, кто сможет на основании серии интервью качественно спроектировать наши процессы.
Но наш опыт поиска специалистов по описанию процессов не оказался удачным.
Завтра расскажу об этом опыте подробнее.

Друзья, опрос показал равенство голосов. Однако я принял к сведению, что подачу материала нужно улучшать и буду делать это.

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

Мой ответ:
Посмотрите как эта компания описывает процессы - там пример приведен на сайте, и не один.
Они в своем описании не опираются на ИТ-систему, например, на 1С.
Возможно, они спецы в процессах, но не в 1С.
Но тогда их описания процессов не сильно помогают в автоматизации.
Искусство описания процессов - в использовании документов, отчетов, справочников 1С системы, которая участвует в процессе.
Именно так у меня оформлен процесс выше - в цвете, повторю его.
Причем цветом выделены объекты 1С систем: желтым - 1С Университет, зеленым - 1С КА.
Вот в чем искусство применения описания процессов для автоматизации - уметь оформлять описание в терминах информационной системы, 1С в частности.

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

В ответ на вашу реплику что они сначала описывают процессы, потом подбирают софт.
У меня не хватает фантазии как можно подобрать софт под приведенное выше с сайта компании описание процессов.
Если указано Подготовка комплекта документов и не указано каких, то любой софт подойдёт.
Знаете почему у них такой подход? Потому что одни люди имеют опыт в описании процессов, но не понимают в ИТ системах, а другие наоборот, знают системы но не могут описать процессы. Думаю, только поэтому они предлагают такую методику.

Если вы сможете описать процессы и ещё в системах разберётесь, поверьте, с руками такого специалиста будут отрывать. Потому что срок разработки ИТ решения резко сможет сократиться.
У меня именно такой опыт