Оптимизация - это же про какие-то улучшения? Без неё информационные системы не внедряют?
Когда говорят об автоматизации, или информатизации, в полном цикле проектных работ часто по умолчанию предполагают выполнение реинжиниринга - анализа и разработки таких рекомендаций по перестройке бизнес-процессов, которые, как минимум, позволят эту автоматизацию реализовать. На самом деле, реинжиниринг для этого требуется не всегда, и они с проектом внедрения АИС в общем смысле - разные вещи. Можно переделывать процессы без дополнительной автоматизации, можно вместе, а порой с бизнесом и так всё в порядке, достаточно скорректировать с помощью ИТ лишь некоторые параметры, а не всю его схему.
Реинжинирингу нужны смыслы - ради чего мы меняемся и куда идём. Их называют критериями (мерой) оптимизации - эффективностью управляют через ресурсоемкость, оперативность и результативность процессов (треугольник). И, по природе любой системы, существуют некие пределы - ограничения оптимизации, коридор возможностей, выше и ниже пороговых значений которого нам нельзя уходить в процессе изменений по критериям. Чтобы сделать реинжиниринг, необходимо определить критерии и ограничения планируемой оптимизации. Если процесс не слишком трудно хотя бы приблизительно описать с помощью функции, вам очень пригодятся математические методы.
Поскольку реинжиниринг - это про поиск оптимального, важно понимать, что оно всегда дихотомично, у функции есть два экстремума, выше и ниже нуля. Только одно из них станет "улучшением" в конкретном кейсе, следует заранее выяснить, какое. Не менее критично сохранять фокус внимания на альтернативных издержках - потенциальных возможностях, неизбежно упускаемых с каждым шагом управления при выборе параметров оптимизации: это цена перемен. С учётом ограничений, принципиально нельзя бесконечно расти по всему полю треугольника эффективности.
Отсюда оптимизация бизнес-процессов - это, скорее, о балансе распределения ресурсов и реализации изменений без ухудшения, по принципу Парето-эффективности: "Всякое изменение, которое никому не приносит убытков, а некоторым людям приносит пользу, является улучшением". Предвижу ваши возражения - всем не угодить, так можно скатиться в бесконечные компромиссы до вырожденного невмешательства, и с вами согласятся критики неоклассической школы экономической теории (например, кембриджский профессор Ха-Джун Чанг). Вместе с тем, современная расширенная трактовка оптимума Парето - принцип компенсации - допускает локальные "ухудшения", если реинжиниринг в целом принесёт достаточно пользы, чтобы их оправдать.
Как при этом понять, что бизнес-процессу нужна оптимизация?
Разумеется, очевидный признак проблем - недостаточная рентабельность, однако не всегда её причины в бизнес-модели, вернее, в самом устройстве бизнеса.
С точки зрения анализа предлагаю взглянуть на схемы процессов as-is (в нотации BPMN) при помощи простого теста:
- на диаграмме одного бизнес-процесса количество участников (ролей - дорожек) аналогично или превышает число шагов (работ);
- хотя бы в одном операторе исключающего ИЛИ более одного исходящего потока ведут сразу к выходу из процесса;
- отсутствуют уведомления ключевых ролей процесса о смене статуса работ;
- в одном процессе больше 2 сложных операторов условия;
- в одном процессе более 2 эскалаций;
- хотя бы в одном операторе объединения И более 3 входящих потоков управления (не по умолчанию);
- в одном процессе более 3 завершающих событий-выходов.
Если вы ответили "Да" более чем в 3 пунктах из 7, вашу схему (ну, и процесс) стоит оптимизировать - для начала попробуйте устранить соответствующие недостатки. Например, п. 1) - свидетельствует о размывании ответственности, чрезмерной зависимости результатов от человеческого фактора и низкой оперативности, значит, можно поработать над сокращением числа участвующих ролей.
Важный момент - при выборе вариантов оптимизации советую соблюдать баланс трёх факторов:
- цена выбора (не только в деньгах);
- влияние выбора внутри и вне процесса;
- ваше личное отношение (экспертиза).