Юрий основал
компанию в начале 90-х, она быстро росла и стала успешной. Юрий нанял кучу
специалистов по продажам, закупкам, логистике, маркетингу и ИТ-шников.
Появилась специализация, регламенты, оргструктура и зоны ответственности. Все
шло нормально пока не начинались кризисы. В кризис все вокруг менялось так
быстро, что старые методы управления переставали работать и Юрий дни и ночи
напролет проводил в компании, раздавал указания, потому что процессы спокойного
времени просто не давали нужного результата. После кризиса 2008 года Юрий нанял
консультанта по оргдизайну и тот ему объяснил, что любая подстройка организации
под изменившиеся внешние условия требует устраивать общение всех лиц,
принимающих решения в своей области со всеми другими ЛПРами. Понятно, что до
маразма не доходим и с уборщицами сбытовую политику компании не обсуждаем, но
все равно общения во врем реорганизации будет много. Консультант это
сформулировал как принцип: "Сложность системы управления должна по
мощности соответствовать управляемой организации. Мы, говорил, он, не можем
поставить движок от Опеля на Мерседес, и не можем посадить тебе людей, которые
только в ларьке торговали".
И Юрий стал
перестраивать организацию, стал устраивать общение всех со всеми. Оказалось,
что никто перестраиваться не хочет, всем и так нормально. Зарплату платят,
премии есть, подчиненных становится все больше. Юрий опять вызвал консультанта
и тот ему объяснил, что это работает так называемый эффект "функциональных
шахт", когда все делают свое дело, и их не волнуют чужие проблемы, своих
хватает. На вопрос Юрия как же выгнать людей из этих шахт, консультант ему
ответил, что надо:
- Напугать.
- Показать, куда надо бежать.
- Получить согласие бежать вместе.
Другими словами,
чтобы перестроить организацию надо:
- Рассчитать системные эффекты сохранения текущей ситуации, показать, что всем будет плохо.
- Показать организационно-техническое решение и план его развития, например, ту же дорожную карту.
- Создать ролевую модель взаимодействия, которая позволит выполнить этот план развития предлагаемого решения. И уговорить всех ЛПРов на эту новую схему взаимодействия, то есть на реорганизацию.
Юрий стал все это
делать и очень быстро обнаружил, что есть три проблемы, которые мешают
выполнять шаги реорганизации.
- Время обнаружения проблем все время росло, т.к. бизнес становился все больше, отчетности становилось все больше, она была все запутаннее, и логика влияния одних показателей на другие становилась комплексной. Никто уже не мог сказать наверняка что было причиной, а что следствием.
- Выработка решений удлинялась, совещания становились все чаще, и все чаще эти совещания оканчивались ничем. Принятые обязательства нарушались, т.к. часто всплывали ситуации, когда начальник чего-то не знал о работе своего отдела и обещал то, чего сделать было нельзя по разным объективным причинам. Да и взаимоотношения между начальниками плохо влияли на профессионализм, люди переходили на личности и выходили из организационной роли.
- Новые люди очень долго входили в должность. Регламентов было уже довольно много, но и они не покрывали всех реально работающих договоренностей по тому, как делать работу. В результате целый месяц новые сотрудники входили в курс дела и еще пару месяцев притирались к коллективу, набирались необходимых знаний.
Все стало слишком
сложно, и Юрий опять пригласил консультанта. В этот раз консультант пришел не
один, а с двумя помощниками. Был длинный обстоятельный разговор, в результате
которого консультанты выдали три рекомендации:
- Нужно ввести мониторинг отчетности. Надо создать панель показателей, по которой можно будет отследить не выполнение функций, как это сейчас, и не только обращать внимание на финансовые показатели, как Юрий привык. Панель показателей должна измерять бизнес-модель организации, качество клиентских сервисов, и простраивать причинно-следственную связь от уровня клиентского сервиса к ключевым процессам, от которых этот уровень сервиса зависит. Консультанты сказали, что таких процессов в компании Юрия всего три, панель будет небольшой.
- Нужно описать ролевую модель взаимодействия в явном виде и требовать от начальников исполнять свои обязанности строго по ролям, которые на них назначены. В первую очередь это важно при подготовке и проведении совещаний, именно совещания были общей больной точкой. Для описания ролевой модели взаимодействия консультанты предложили создать модель бизнес-архитектуры предприятия и связать ее с картами ИТ-ландшафта, которые недавно создал новый ИТ-директор.
- Нужно ввести
управление знаниями, выделять ключевые знания людей о том, как работает
бизнес, и записывать их в базу знаний. Только это должны быть не
регламенты и даже не вики, консультанты сказали, что все это не работает.
Они порекомендовали создать связанную модель бизнес-архитектуры
предприятия с графовой базой данных neo4j, в которой-то и вести все знания о том, как
работает бизнес. И даже показали работающий вариант. Все оказалось совсем
не сложно и не страшно, с этим явно бы справились и текущие подчиненные https://neo4j.com/use-cases/knowledge-graph/
Все было
понятно звучало просто, но пока все
вместе не заработало, прошла куча времени. Но дела наладились, Юрий опять стал
ходить в отпуск, мрачность и суровые шутки ушли, и он опять стал встречаться с
немногими друзьями, которые еще остались в Москве. Кризис коснулся многих,
дотянулся самыми разными путями. И на салфетке в ирландском баре он описал всю
концепцию:
"Оперативная
обстановка должна быть на карте, коллективное обсуждение ведется только по этой
карте".
- Построить карту территории бизнеса, учесть в ней бизнес-модель.
- Использовать карту для управления коллективным обсуждением, обновлять карту по мере поступления новых данных.
- Должностные инструкции и поручения оформлять как чек-листы, делить участки карты с подчиненными.
Такая карта и
называется цифровым двойником организации, а ключевая сложность не в том, чтобы
ее создать, а том, как приучить людей ей пользоваться. Про это Юрий расскажет
дальше. Я, по крайней мере, на это надеюсь.
Комментариев нет:
Отправить комментарий