Стоматология, на мой взгляд, идеальный учебный пример для разговора о прототипировании. С одной стороны, это вроде бы типовой бизнес: пациенты, врачи, расписание, оплата. На рынке десятки готовых программ, и каждая обещает «всё для клиники в одном окне». С другой стороны, я не видел ещё двух клиник, которые работали бы одинаково. И каждый раз, когда владелец клиники приходит ко мне после неудачного внедрения коробочной системы, разговор начинается с одной и той же фразы: «Вроде всё есть, но работать в этом невозможно».
Давайте разберём на этом примере, зачем бизнесу индивидуальный прототип, почему его нельзя заменить демонстрацией готовой CRM, и как он экономит деньги ещё до того, как написана первая строчка рабочего кода.
Почему стандартная CRM не знает, что такое зуб
Типовая CRM мыслит сделками. Есть клиент, есть воронка, есть этапы, есть сумма. Для отдела продаж это прекрасно. Но в стоматологии «сделка» растягивается на месяцы, разбивается на десяток визитов к трём разным специалистам, привязана к конкретному зубу на зубной формуле, зависит от снимков, анамнеза и аллергий, и в середине может полностью поменяться, потому что под пломбой обнаружилось то, чего никто не ждал. Плюс расходные материалы: анестетик, импланты, слепочная масса, каждый со своей партией и сроком годности, и всё это нужно списывать на конкретного пациента и конкретного врача.
Медицинские информационные системы (МИС) знают про историю болезни, но часто ничего не знают про бизнес: про загрузку кресел, про то, почему пациент не вернулся на второй этап лечения, про маржинальность направлений. Получается, что у клиники в руках либо калькулятор продаж, либо электронная медкарта, а ей нужен организм, в котором всё это связано. И связано именно так, как устроена эта клиника, а не средняя клиника по больнице.
Прототип как макет зуба перед коронкой
Хороший стоматолог не ставит коронку наугад. Сначала снимок, потом слепок, потом временная коронка, и только когда пациент походил с ней, пожевал, привык к прикусу, изготавливается постоянная. Никто не считает это лишней тратой времени. Это просто способ не переделывать дорогую работу.
Прототип информационной системы работает точно так же. Это кликабельная модель будущей системы, собранная под конкретную клинику: экраны администратора, врача, ассистента, директора, с настоящими сценариями и правдоподобными данными. В нём можно записать пациента, перенести визит, открыть зубную формулу, составить план лечения, списать материалы, посмотреть отчёт. За кадром нет настоящей базы и интеграций, но для того, кто им пользуется, он ведёт себя почти как живой. И как временная коронка, он показывает, где «давит», задолго до того, как Вы заплатили за постоянную.
Где прячется бутылочное горлышко
Самое ценное в прототипе не красота экранов, а то, что он вскрывает. Я много раз видел одну и ту же картину. Мы показываем прототип администратору клиники, она начинает записывать пациента и через минуту говорит: «А у нас так нельзя, потому что этот врач работает только с ассистенткой, а она по вторникам в другом филиале». Это правило не было записано ни в одном документе, ни в одном брифе. Оно жило в голове у администратора. Без прототипа мы бы узнали о нём после запуска, когда система уже записала бы пациентов к врачу без ассистента.
Или директор смотрит на отчёт по загрузке кресел и вдруг понимает, что вопрос «сколько зарабатывает кресло в час» ему важнее, чем «сколько зарабатывает врач в месяц». Это меняет структуру данных, расписание, расчёт зарплаты. На этапе прототипа такая правка стоит несколько часов работы проектировщика. На этапе готовой системы она стоит перестройки фундамента.
Ошибка, найденная на прототипе, стоит часы. Та же ошибка, найденная после запуска, стоит месяцы и нервы всего персонала.
Как мы делаем такие прототипы
В Ingello индивидуальный прототип у нас отдельный продукт, а не бесплатная картинка перед продажей. Процесс выглядит так. Сначала мы проводим несколько коротких интервью с теми, кто будет в системе жить: администратор, врач, ассистент, бухгалтер, владелец. Не о том, «какие функции Вам нужны» (на этот вопрос все отвечают одинаково), а о том, как проходит обычный день, что раздражает, где теряется время и деньги. Потом собираем карту процессов и находим места, где процессы сталкиваются друг с другом. Потом строим прототип и даём его в руки, буквально: садим администратора за компьютер и просим записать трёх пациентов.
Отдельно скажу, почему это стало для нас дешевле, чем было раньше. Наш генератор Fractal позволяет описывать экраны и данные декларативно, и прототип собирается из того же описания, из которого потом может вырасти рабочая система. Поэтому прототип не выбрасывается после согласования, а становится скелетом будущей разработки. Если же оказывается, что клинике нужен типовой учёт склада и продаж, то основой служит Forma, и прототип показывает, что в ней нужно доработать под медицину.
Что делать, если Вы владелец клиники
Если Вы выбираете систему для своей клиники, не начинайте с демонстраций готовых программ. Демонстрацию всегда проводит продавец, и всегда по идеальному сценарию. Начните с того, что запишите три самых болезненных процесса: где теряются пациенты, где теряются материалы, где теряется время врача. Потом попросите любого поставщика, хоть коробочного, хоть заказного, показать Вам именно эти три процесса на Ваших данных. Кто не может этого сделать без «ну, это мы потом настроим», тот, скорее всего, не сможет и после.
И помните, что этот подход работает далеко не только в стоматологии. Любой бизнес, который кажется типовым, при близком рассмотрении оказывается уникальным в двух-трёх местах. Именно эти места и определяют, будет система помогать или мешать. Прототип нужен, чтобы найти их дёшево. Здоровых Вам процессов, коллеги, и пусть временная коронка сядет с первого раза.
