Как меняется компания во время проекта
Запрос на проект по управлению бизнес-процессами часто звучит утилитарно: описать, как работают подразделения, и подготовить регламенты.
Консультант начинает с интервью и разбора фактической работы. Каждый руководитель подробно объясняет свою функцию, её правила и ограничения. Но о том, что происходит с результатом после передачи следующему подразделению, обычно говорят значительно меньше.
Один отдел считает, что передал готовый результат. Другой получает его и обнаруживает, что не хватает данных или не согласованы условия дальнейшей работы.
На первых обсуждениях нередко звучит:
«Мы свою часть выполнили».
И формально это может быть правдой. Подразделение действительно выполнило предусмотренные для него действия. Но полученного результата недостаточно, чтобы следующий участник мог продолжить работу.
Когда в ходе проекта команда вместе разбирает всю цепочку, становятся видны связи, которые не проявляются внутри отдельной функции. Что именно должен получить следующий участник? Какие данные нужны ему для работы? Где заканчивается ответственность одного подразделения и начинается обязательство другого? Что происходит, если результат не соответствует условиям передачи?
Постепенно меняется характер обсуждений. Участники начинают смотреть не только на собственные операции, но и на то, как их действия влияют на общий результат.
Для меня ценность проекта не ограничивается разработкой модели и регламентов. Важно, чтобы команда освоила другой способ смотреть на работу: видеть процесс целиком, связывать действия разных подразделений с результатом и рассматривать отклонение как повод проверить порядок работы.
Модель процесса даёт участникам общий язык для обсуждения работы. Регламент закрепляет принятые договорённости. А новая управленческая культура начинает формироваться тогда, когда совместный анализ и принятие решений становятся привычной практикой.
Тогда документы не остаются файлами, которые консультант передал заказчику в конце проекта. При изменении условий команда понимает, что нужно пересмотреть, какие договорённости изменить и кого подключить к решению.
Но один из самых важных результатов проявляется уже после завершения проекта - когда сотрудники продолжают пользоваться общей логикой процесса не только в обсуждениях, но и при принятии повседневных решений.
И тогда функциональные границы перестают быть пределом управленческого взгляда.
Ещё больше обо мне | sergey-suslov.ru
· 29.10
Сергей, очень точное наблюдение про «разрыв» на стыке подразделений. Часто бывает, что регламент на бумаге идеален, а в реальности информация теряется или передаётся в неполном виде именно в момент перехода ответственности. Как вы обычно предлагаете фиксировать эти критерии готовности результата, чтобы они не оставались только в тексте документа?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 29.10
Никита, доброго дня!
Я не совсем понял, о каких критериях вы говорите.
Раскройте свой вопрос, пожалуйста
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 29.10
Сергей, извините, не совсем ясно выразился. Я имел в виду критерии качества самого объекта: что именно должно быть заполнено в CRM при передаче лида между отделами, чтобы работа шла без уточнений. Как вы считаете, помогут ли здесь жесткие цифровые чек-листы? Мы в Senvora как раз помогаем автоматизировать такие стыки процессов в CRM, чтобы исключить человеческий фактор. Предлагаю обсудить, какие поля критичны для вашего процесса.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 29.10
Для моего процесса? Никита, мы точно обсуждаем мой пост?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 29.10
Сергей, прошу прощения, если перескочил тему. Я имел в виду именно ваш тезис про разрыв между подразделениями. Просто хотел уточнить, как вы считаете, помогает ли автоматизация контроля заполнения данных в CRM решить проблему, когда один отдел передает другому «недоделанный» результат. Это был лишь пример того, как технический инструмент может поддержать внедряемую вами управленческую культуру.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён