Кейc: как владелец клиники в Туле “внедрял систему” — и почему всё развалилось Название клиники и города изменены Клиника «Семейная линия», Тула. Формат: терапевты, УЗИ, анализы, стоматология, процедурный кабинет. Команда: 22 человека. Владелец — Игорь, врач по образованию, управляет клиникой сам. К концу года клиника выросла, но Игорь почувствовал знакомое: — график постоянно “плывёт”, — администраторы не удерживают запись, — врачи работают по-разному, — жалобы и возвраты стали чаще, — владелец снова каждый день тушит пожары. Игорь решил: “Нужно внедрить систему”. Попытка №1: «Сделаем как у взрослых» Он сделал всё, что обычно советуют: 1. Купил CRM и сервис для записи 2. Ввёл KPI для администраторов и врачей 3. Написал регламенты для ресепшн и процедурной 4. Запустил еженедельные планёрки 5. Назначил “ответственных” Первые 2 недели стало лучше. На третьей неделе началось привычное: — сотрудники начали спорить, “что считать результатом”, — отчёты заполнялись формально, — KPI вызывали раздражение, — планёрки превращались в разговоры “кто виноват”, — владелец снова включился руками. Через 6 недель система фактически умерла. Что именно пошло не так Ошибка 1. Начал с инструментов, а не с архитектуры CRM и KPI появились, но никто не понимал: — какие управленческие роли есть в клинике, — кто держит какой результат, — где заканчивается ответственность ресепшн и начинается медчасть. В итоге CRM стала “табличкой для галочки”, а KPI — “палкой”. Владелец хотел порядок, но построил надстройку над хаосом. Ошибка 2. Пытался собрать всё сразу Игорь одновременно: — внедрял CRM, — переписывал регламенты, — менял мотивацию, — вводил собрания. Команда оказалась перегружена изменениями. Люди начали защищаться: — “зачем это всё”, — “мы и так работаем”, — “опять новая система”. Вместо устойчивости он получил сопротивление. Ошибка 3. Делегировал внедрение, не зафиксировав каркас Игорь поручил внедрение: — старшему администратору + бухгалтеру. Но “каркас управления” не был задан владельцем: — какие контуры должны появиться в первую очередь, — какие показатели действительно важны, — какой ритм решений нужен клинике. В результате внедряли то, что было удобно: — отчёты ради отчётов, — показатели ради показателей, — процессы ради процессов. Система получилась “не под цель клиники”, а под занятость исполнителей. Ошибка 4. Ожидал быстрый идеальный результат Игорь хотел, чтобы за 1–2 месяца клиника стала “как сетевой игрок”. Но “управленческое ядро” нельзя поставить как приложение. Оно собирается поэтапно: — минимальная версия v1, — закрепление ролей, — показатели, — цикл решений, — затем усиление. Когда идеала не случилось быстро — мотивация владельца упала, и всё остановилось. Поворот: что изменило ситуацию После провала Игорь сделал одну ключевую вещь: он перестал “внедрять систему” и начал собирать управленческое ядро v1. 1. Сначала — диагностика: где реально держится управление (всё оказалось на владельце). 2. Затем — минимальный каркас: • медицинская часть (качество и стандарты) • ресепшн (запись и коммуникация) • диагностика/процедуры (исполнение) • финансы (денежный цикл) З3. акрепили 4 управленческие роли: • медрук (качество) • руководитель ресепшн (запись/сервис) • руководитель диагностики (точность/готовность) • финансы (маржинальность/расходы) 4. Выбрали 6 показателей (только ключевые): • конверсия запись → визит • загрузка • повторные визиты • жалобы/претензии • средний чек • прибыльность 5. Ввели один ритм: еженедельный цикл решений 60 минут. И только после этого CRM и регламенты “легли” нормально — потому что появился каркас. Итог кейса История клиники в Туле — не исключение. Это типичная ситуация для бизнеса, который вырос быстрее, чем его система управления. Первая попытка “внедрить порядок” провалилась не потому, что команда слабая. И не потому, что инструменты плохие. Она провалилась, потому что не была собрана управленческая конструкция. Системность нельзя внедрить сверху. Её можно только послед