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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кратко опишу наш опыт поиска специалистов по описанию процессов.
Нам порекомендовали довольно известного специалиста с большим количеством соответствующего обучающего видео на YOUTUBE. Специалист работал с системой CAMUNDA, чем-то похожей на VISIO. Мы договорились со специалистом, что он опишет один процесс МИРБИС.
Описание мы готовы были принять в том стандарте, который ему покажется наиболее целесообразным. Если описание одного процесса нам понравится, мы были готовы предложить ему на подряд и на остальные процессы.
Вот какое описание мы получили:

В чём преимущество этого описания?
В том, что оно сделано по дорожкам – исполнителям: деканат, второй операционный зал, бухгалтерия. У каждого подразделения свои задачи в рамках процесса, и видно, как задачи передаются от одного исполнителя другому.
Но в чём минус описания?
Процесс не заканчивается результатом – документом. Непонятно, например, какой документ рождается в результате процесса «Рассчитать фактически отработанный объём работ». Кроме того, в этой системе невозможно раскрыть процесс на подпроцессы, получить какое-то описание. Можно прикреплять ссылки, но это не совсем удобно.
Откровенно говоря, я был разочарован таким описанием процесса, потому что не понимал, как использовать описание для дальнейшей автоматизации. Поэтому сотрудничество со специалистом развивать не стали и продолжили описание процессов собственными силами.

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